Re: Attribute Exchange pre-draft 5

In a user-centric model, what's the difference? (Seriously) On Apr 2, 2007, at 12:14, 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

Re: Attribute Exchange pre-draft 5

I have uploaded changes proposed at the beginning of this thread into SVN; if you're up to reading the xml source, it can be viewed here: To summarize the open issues: a) ax.mode vs multiple URIs b) No useful gain

Re: Attribute Exchange pre-draft 5

On 2-Apr-07, at 12:10 PM, Josh Hoyt wrote: > On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: >> - Added ax.mode parameters to all messages, to unambiguously identify >> the message types; the values are: >> fetch_request >> fetch_response >> store_request >> stor

Re: SREG namespace URI rollback

On 4/2/07, Recordon, David <[EMAIL PROTECTED]> wrote: > Sure, though I think there has also been a desire to do a bit of an > actual rev to SREG to be more of a 1.1 version in terms of either > explicitly supporting additional fields (such as avatar) or allowing > field names to be URIs themselves

RE: SREG namespace URI rollback

Sure, though I think there has also been a desire to do a bit of an actual rev to SREG to be more of a 1.1 version in terms of either explicitly supporting additional fields (such as avatar) or allowing field names to be URIs themselves versus a hard-coded list of properties. --David -Origin

Re: SREG namespace URI rollback

After a chat with Josh, we settled our dispute by agreeing on the following: On 2-Apr-07, at 2:44 PM, Josh Hoyt wrote: > I think it would be reasonable to always use "sreg", if for no other > reason than for clarity, but re-using the Type URI as the namespace > alias instead of creating a new on

Re: Attribute Exchange pre-draft 5

On 2-Apr-07, at 2:41 PM, Rowan Kerr wrote: > 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 empt

Re: SREG namespace URI rollback

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: > But they are not the same -- the namespace alias can be different > than "sreg". Are you suggesting that SREG1.1 must always use the > "sreg" namespace alias? They *are* the same protocol, going over different transports (that is, embedded in dif

Re: Attribute Exchange pre-draft 5

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 o

Re: Attribute Exchange pre-draft 5

On 4/2/07, Rowan Kerr <[EMAIL PROTECTED]> wrote: > On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote: > > My intuition is that a server could advertise what attributes it > > supports rather than including this information in a user-specific > > response. So, -0.5 on this. If it does go in, I'd say -1 on ma

Re: Attribute Exchange pre-draft 5

On 4/2/07, Rowan Kerr <[EMAIL PROTECTED]> wrote: > 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

Re: Attribute Exchange pre-draft 5

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

Re: Attribute Exchange pre-draft 5

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 val

Re: SREG namespace URI rollback

On 2-Apr-07, at 2:08 PM, Josh Hoyt wrote: > On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: >> Sorry - I may be missing something, but I still say the problem >> remains: if a SREG1.1 party builds a message with a namespace alias >> different than "sreg", it can confuse the other party which ma

Re: SREG namespace URI rollback

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: > Sorry - I may be missing something, but I still say the problem > remains: if a SREG1.1 party builds a message with a namespace alias > different than "sreg", it can confuse the other party which may be > expecting specifically "sreg". > > Or, put

Re: SREG namespace URI rollback

On 2-Apr-07, at 1:17 PM, Josh Hoyt wrote: > On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: >> I think the missing namespace in SREG1.0 can cause problems; take >> this example: > > I was not proposing that we drop the namespace. Just that we don't > introduce a new URI when the protocol is oth

Re: SREG namespace URI rollback

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: > I think the missing namespace in SREG1.0 can cause problems; take > this example: I was not proposing that we drop the namespace. Just that we don't introduce a new URI when the protocol is otherwise identical, and instead just use the existing t

Re: SREG namespace URI rollback

Or even: > - RP doesn't support SREG1.0, but does support 2.0 extensions > - RP sees in an XRDS that the OP supports SREG1.* (if the same > namespace is used for both) > - the OP actually only supports SREG1.0 - RP sends a SREG1.1 request, but with openid.ns.some_alias=http://openid.net/

Re: SREG namespace URI rollback

Josh, On 2-Apr-07, at 12:43 PM, Josh Hoyt wrote: > I'd like to change the simple registration specification so that it > uses the type URI that is currently in use in at least PIP and > MyOpenID as the namespace URI instead of defining a new value. > > As far as I can tell, the only difference be

SREG namespace URI rollback

I'd like to change the simple registration specification so that it uses the type URI that is currently in use in at least PIP and MyOpenID as the namespace URI instead of defining a new value. As far as I can tell, the only difference between the 1.0 and 1.1 simple registration specifications is

Re: Server-to-server channel

Chris, On 2-Apr-07, at 11:50 AM, Chris Drake wrote: > I've also noticed a lot of discussion about attributes, which begs the > question about how to handle things that change (eg: If I've given out > my email address to a dozen web sites, and then I change it, how does > my OpenID server propagat

Re: Attribute Exchange pre-draft 5

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: > - Clarified that a fetch response parameter MUST be sent for each > requested attribute, with an empty value if the user did not supply one. > along the lines of the above, so that the RP can fallback to > alternative data collection meth

Spec suggestion: Appendix A.4. HTML Identifier Markup: livejournal replacement

Hi, I'd like to see the "livejournal" examples replaced with ones from somewhere that actually supports 2.0 and XRI's - it's very confusing to pop over to livejournal and find that nothing works properly... Kind Regards, Chris Drake ___ specs mailing

Re: Attribute Exchange pre-draft 5

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 and the ones > not supported by t

Re: Attribute Exchange pre-draft 5

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: > - Added ax.mode parameters to all messages, to unambiguously identify > the message types; the values are: > fetch_request > fetch_response > store_request > store_response_success > store_response_failure

Web Access Management

Unlike blog sites and Internet startups, many large enteprises have purchased Web Access Management products such as Tivoli Access Manager, Netegrity Siteminder, etc where authentication doesn't occur by embedding code into the application. Is anyone directly working with any of the vendors in t

Server-to-server channel

Hi, I've been away a while - is there any server-to-server mechanism built into OpenID yet? I've noticed folks wanting to build a "log off" facility for OpenID, which essentially requires the users server to inform whatever places the user has been recently to "drop" any session info. I've also

RE: Features for Future Versions

I also agree with the feedback however I wanted to just pass along how I am using authentication and authorization on a series of applications that I am working on. I have a couple of applications that use standard openid authentication using XRDS documents but they also require the user to be a

RE: Features for Future Versions

Before we get into the discussions on this list (and hopefully elsewhere), it would be great if you (and anyone else contributing) could make a clear IPR statement about your intent with this new functionality. If you wanted to use Microsoft's Open Specification Promise as a template, that would b

RE: Features for Future Versions

James, I agree with Dick's feedback. I don't believe OpenID, as an overall Internet identity framework, is subject to either limitation you asked about. But we must work our way up into each of those areas of functionality. The more you can tell us about specific functions and use cases you'd lik

Re: Features for Future Versions

On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote: > I originally joined this list with the hopes of injecting support > for relationships, authorization and attestation into the > specification but have been somewhat disappointed. I do have the > following questions? > > 1. Wil

Features for Future Versions

I originally joined this list with the hopes of injecting support for relationships, authorization and attestation into the specification but have been somewhat disappointed. I do have the following questions? 1. Will OpenID avoid incorporating features where identity selectors such as Cardspac