On 28-Aug-07, at 6:11 PM, Johnny Bufu wrote:
On 27-Aug-07, at 7:05 PM, Peter Williams wrote:
A. fragment identifiers on user input are to be removed. Do not
remove
the separator.
Good thing we didn't call it final just yet. In my mind the separator
was part of the fragment, but re-reading
On 31-May-07, at 1:45 AM, Drummond Reed wrote:
To make this new section easy to review, we've put it on the XRI TC
wiki at:
http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris
In Section 8.2:
the value of the head element whose http-equiv attribute is X-
On 25-May-07, at 11:18 AM, Peter Watkins wrote:
It's too bad Yadis doesn't allow embedding the XRDS document in
something like a META tag to avoid that second Yadis HTTP request
If you send an Accept header that includes application/xrds+xml
the OP can return the XRDS document on the first
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 would seem to be already url-encoded by
the
On 8-Apr-07, at 1:01 PM, Mark Wahl wrote:
FYI if you are carrying attribuets in OpenID AX that are equivalent to
LDAP attributes with attribute types being standardized in the
IETF, then
you could use our LDAP schema definition metadata. We have
resolvable
HTTP URIs for each of the
On 9-Apr-07, at 8:23 PM, Recordon, David wrote:
Is there a list anywhere? I didn't find one in the documents and I
think this list would benefit everyone in the conversation. I'm
just curious as to the fields you're expecting an OP to implement.
While at Standard, I ended up hosting our
On 10-Apr-07, at 12:21 AM, Dick Hardt wrote:
On 9-Apr-07, at 5:24 PM, Recordon, David wrote:
Yes, I agree an upgrade path from SREG is needed. We could
however do
something as simple as
http://openid.net/specs/openid-simple-registration-
extension-1_0.html#nickname for the existing SREG
On 10-Apr-07, at 9:39 AM, Josh Hoyt wrote:
On 4/10/07, Rowan Kerr [EMAIL PROTECTED] wrote:
Since
the main difference I'm seeing at the moment is that SREG doesn't
specifically request each value it wants, except in
openid.sreg.required
and openid.sreg.optional.
Um, that is exactly how
On 3-Apr-07, at 9:18 AM, Anders Feder wrote:
* The RP can't know the status of the information it is working with -
it just have to assume that the attributes it has in store are up-
to-date.
The RP can send an update_url to the OP when it fetches the
attributes, so it will get new values
On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote:
What about attributes whose value could reasonably be an empty string?
It would be reasonable to answer don't do that, I'm just curious how
you expect this case to be handled.
I'd say it's up to the RP to decide whether the data returned is
valid
On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote:
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote:
One feature we didn't figure out yet if its benefits would be worth
the added complexity:
- in a fetch response, distinguish between attributes
that the user didn't *want* to release
On 2-Apr-07, at 5:27 PM, Josh Hoyt wrote:
I'm thinking about differentiating between an attribute that's not
available and an attribute that *is* available, but its value is .
I. e. difference between a null pointer, and a pointer to an empty
string.
That was part of why I had the idea of
In all my time spent reading and implementing the OpenID Authn 2
spec, this particular detail escaped me. Johnny Bufu pointed it out
to me the other day while we were going through some Attribute
Exchange tests.
http://openid.net/specs/openid-authentication-2_0-11.html#extensions
To
On 13-Mar-07, at 6:23 PM, Drummond Reed wrote:
If I understand you correctly here, what you are saying is that
openid.ns.*
prefixes work almost identically to XML namespace (xmlns) prefixes,
i.e.:
* the prefix is never globally defined by dynamically defined on a
per-instance basis
*
On 1/30/07, Josh Hoyt [EMAIL PROTECTED] wrote:
*snip*
While it is true that since the link relationship names changed, the
openid2 is technically redundant, I think it is much clearer to
everybody what is going on if the link relationship contains the
version number. If the protocol version
opaque, or if it's nicer
because the messages are now more standard.
I suppose the main OpenID specs already rely on the
absence of values rather than the presence or naming
of, so maybe it's more in keeping with the general protocol.
-Rowan
--
Rowan Kerr
Senior Web Programmer, Standard
On 1/31/07, Recordon, David [EMAIL PROTECTED] wrote:
I'm happy changing it from AJAX. I think it was originally used since
AJAX is a bit overloaded already and people normally understand the
flashy non-reloading sort of thing when saying it.
I suppose some people might, but for a developer
The openid2.* links bug me a little.. but due to no openid.ns being
defined in the 1.x protocol, maybe there is no other way to specify by
HTML discovery that your OP is 2.0 capable. Would it be bad to have a
openid.version link instead?
Also, the spec mentions AJAX interactions, but I don't see
a whitepaper (yet?), but we're using openid for listener
club information and working with our 3rd party service providers to
make their services openid-enabled so they can access one common set
of data.
-Rowan
--
Rowan Kerr
Senior Web Programmer, Standard Interactive
tel:+14169344451
xmpp:[EMAIL
On 1/5/07, Dick Hardt [EMAIL PROTECTED] wrote:
The Attribute Type model is such that anyone with a domain can define
new attributes. No need for central control. We created a set of what
we thought were common attributes, but that does not mean anyone has
to use them.
Being able to define
On 1/3/07, Dick Hardt [EMAIL PROTECTED] wrote:
Our proposal was to have the schemas for OpenID hosted at
schema.openid.net. Some people expressed concerns about having them
be on openid.net.
Do you have any suggestions? Anyone else have an opinion? Does anyone
care? ;-)
Being part of the
to
update it for Draft 2 if someone can make the default types site and
accompanying XML docs available.
Thanks,
-Rowan
--
Rowan Kerr
Senior Web Programmer, Standard Interactive
tel:+14169344451
xmpp:[EMAIL PROTECTED]
http://standardinteractive.com/
___
specs
On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote:
-Original Message-
From: Recordon, David
But the security warnings will still exist:
- RP redirects me to http on IdP
- IdP redirects me to https on IdP for login page (warning)
no warning on GET redirects
If GET is
On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote:
I think you need the ability for a user to change his identifier at the
RP (as George notes below) and also at the IdP.
Isn't this was already covered in the spec? You accomplish this by
creating an HTML page on some website you control with
24 matches
Mail list logo