Re: Attribute Exchange pre-draft 5
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote: Since draft_4 [1] we've done some implementation and testing (as well as listened to community's suggestions on related issues), and have incorporated some changes into a pre-draft-5. Before publishing it I would like to see your comments about them or about other features / changes that would be useful in AX. If I understand correctly, the response to a request for an attribute with count.x=1 is different from the response for a request with no count specified, even though the meaning is the same. (namespacing left off for clarity) Request: .type.a=http://example.com/a .count.a=1 .type.b=http://example.com/b Response: .type.a=http://example.com/a .count.a=1 .value.a.1=avalue .type.b=http://example.com/b .value.b=bvalue Even though the request for a and b have equivalent meaning (send zero or one values for this attribute) the response MUST encode them in different ways. I think this is ugly, because the detail of the way that the attribute was requested has to be preserved in the code, to ensure that the response can be encoded correctly. (it's not sufficient to just default the count to one if it's not specified) Is there a reason that it's specified this way? I'd prefer if there was only one way to do it. Also, can the count be zero in the response? it seems like that's OK, and if it is, it'd address my concern about overloading zero-length strings to mean no value. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Johnny Bufu wrote: This is basically a push approach, as opposed to the pull approach you were suggesting. I'm new to OpenID, and no engineer, but I have to say that I have a bad feeling about this 'push' approach. It inverts the relationship between client and server and seems entirely contrary to the stateless spirit of the Web: * 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. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. * While the RP's requests the information, the OP is made responsible for doing the work associated with distributing it. * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 3-Apr-07, at 3:32 AM, Josh Hoyt wrote: If I understand correctly, the response to a request for an attribute with count.x=1 is different from the response for a request with no count specified, even though the meaning is the same. (namespacing left off for clarity) Request: .type.a=http://example.com/a .count.a=1 .type.b=http://example.com/b Response: .type.a=http://example.com/a .count.a=1 .value.a.1=avalue .type.b=http://example.com/b .value.b=bvalue Even though the request for a and b have equivalent meaning (send zero or one values for this attribute) the response MUST encode them in different ways. I think this is ugly, because the detail of the way that the attribute was requested has to be preserved in the code, to ensure that the response can be encoded correctly. (it's not sufficient to just default the count to one if it's not specified) Is there a reason that it's specified this way? I'd prefer if there was only one way to do it. Good point. Either .count. has to be more then 1 in a request so that there is only one way to do it, or the response could be in either form where .count.=1 to be consistent with the request being able to be in either form. Also, can the count be zero in the response? it seems like that's OK, and if it is, it'd address my concern about overloading zero-length strings to mean no value. Another good point. I agree it should be able to be zero. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Good questions to tease out the logic behind the architecture Anders, responses to each of your points below ... On 3-Apr-07, at 6:18 AM, Anders Feder wrote: Johnny Bufu wrote: This is basically a push approach, as opposed to the pull approach you were suggesting. I'm new to OpenID, and no engineer, but I have to say that I have a bad feeling about this 'push' approach. It inverts the relationship between client and server and seems entirely contrary to the stateless spirit of the Web: There are two common client server design patterns. Request / Response and Publish / Subscribe. * 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 has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. * While the RP's requests the information, the OP is made responsible for doing the work associated with distributing it. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Now the OP and RP only need to move data if the data has changed and the user wants to push the update to the RP. * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. The same flow could happen between the RP and dependent services. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On 3-Apr-07, at 8:24 AM, Dick Hardt wrote: On 2-Apr-07, at 11:50 AM, Chris Drake wrote: User Centric implies that sites don't store anything about me, and that whenever they need to know stuff (eg: my email), they instead ask my OpenID server, which returns them the answer (unless I've since revoked permission or whatever). Again - server-to-server (although this time in the reverse direction) applies here. I understand why you think User Centric implies a site does not store anything about me. oops I *don't* understand why you think ... User Centric implies that the user is the center of the transaction. Server to server is so NOT User Centric! -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
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 when the user changes them at the OP. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. Not sure I understand this. OP's normally would not have interest in any particular RPs the User has interest in RPs :) Although it is up to the individual OP to set rules about who it wants to talk to. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. You're free to publish the RDF for the attributes you support... then they are reference-able aren't they? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Promoting OpenID
As an end-user to user-centric approaches, I have noticed an interesting pattern. Microsoft does a wonderful job of selling Cardspace as a solution to others who develop in Microsoft languages. Likewise, there are tons of vendors that can offer solutions for large enterprises to purchase but no one is promoting user-centric approaches to the vendors us large enterprises do business with in terms of getting them to embrace user-centric approaches within their own code base. Sure, we can as consumers raise awareness, but I would like to understand thoughts on other than procurement, how could we make this more pervasive? Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Rowan, Thanks for your response. Again, I have no formal education, so don't bother if my comments are worthless. I just want to specify the concerns I do have, based on my own experience, in case they are of any use to the process. Rowan Kerr skrev: The RP can send an update_url to the OP when it fetches the attributes, so it will get new values when the user changes them at the OP. But the RP can't know if the update_url is honored, i.e. if it will ever receive any updates from the OP. Imagine an RP requesting your bank account number X from your OP. Time goes by, and your OP goes out of business. Later, you switch banks and your account number X is assigned to someone else. In the meantime, the RP has been preparing a payment for a job you have done for them. The RP look up your account number in its database, and see X. And since the RP has not received any updates to your bank account information, it reasons that your account number is still X and consequently disburse your payment on a stranger's account ... One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? Yes, or if the Store request never leaves the OP server, for whatever reason. Not sure I understand this. OP's normally would not have interest in any particular RPs the User has interest in RPs :) Although it is up to the individual OP to set rules about who it wants to talk to. User interest in RP's come and go, but this is not reflected in the OP's database. After a couple of years use, each user is likely to have some thousands of RP entries associated with their identity in the OP's database, while the user may only have active interest in a fraction of these. You're free to publish the RDF for the attributes you support... then they are reference-able aren't they? My point was that attributes does not have a canonical identifier that can be passed on to someone else who might put the attribute to better use. As far as I can see, the wheel more or less has to be reinvented each time someone wish to exchange attribute references (unless someone outside OpenID standardize the exchange process). Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Promoting OpenID
People might be, though nothing real formal that I personally know of. You volunteering? :P --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Monday, April 02, 2007 8:15 AM To: specs@openid.net Subject: Promoting OpenID As an end-user to user-centric approaches, I have noticed an interesting pattern. Microsoft does a wonderful job of selling Cardspace as a solution to others who develop in Microsoft languages. Likewise, there are tons of vendors that can offer solutions for large enterprises to purchase but no one is promoting user-centric approaches to the vendors us large enterprises do business with in terms of getting them to embrace user-centric approaches within their own code base. Sure, we can as consumers raise awareness, but I would like to understand thoughts on other than procurement, how could we make this more pervasive? Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Promoting OpenID
More likely that the people promoting OpenID to large organizations are vendors and don't particularly want to tell their competitors what they are doing. Now, imagine if there were like-minded vendors getting together to form some sort of marketing organization to promote OpenID to a variety of audiences, including large enterprises... ;-) -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Tuesday, April 03, 2007 12:18 PM To: McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Promoting OpenID People might be, though nothing real formal that I personally know of. You volunteering? :P --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Monday, April 02, 2007 8:15 AM To: specs@openid.net Subject: Promoting OpenID As an end-user to user-centric approaches, I have noticed an interesting pattern. Microsoft does a wonderful job of selling Cardspace as a solution to others who develop in Microsoft languages. Likewise, there are tons of vendors that can offer solutions for large enterprises to purchase but no one is promoting user-centric approaches to the vendors us large enterprises do business with in terms of getting them to embrace user-centric approaches within their own code base. Sure, we can as consumers raise awareness, but I would like to understand thoughts on other than procurement, how could we make this more pervasive? Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Promoting OpenID
Gabe, I think you nailed it. The problem I run across is that my interest in using OpenID is all about getting a federation of sorts up and working within my insurance vertical which contains 250 distinct competitors. Getting emails offlist privately with vendors marketing uniquely to me is not only frustrating but doesn't actually help my goal. I don't want to choose a vendor at this time in that we all as a vertical need to agree on some other things first, so the thought of me running around attempting to coordinate a cross-company marketing event is problematic. Likewise, in terms of being in a regulated industry, I couldn't do this except in very publicly observable ways such as asking folks to blog on things, etc. Collusion is important and the best way to avoid is to ask folks who want to sell us software to market in other than a point-to-point way. -Original Message- From: Gabe Wachob [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 4:44 PM To: 'Recordon, David'; McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Promoting OpenID More likely that the people promoting OpenID to large organizations are vendors and don't particularly want to tell their competitors what they are doing. Now, imagine if there were like-minded vendors getting together to form some sort of marketing organization to promote OpenID to a variety of audiences, including large enterprises... ;-) -Gabe * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Promoting OpenID
Imagine the waves through the technology community when end-customers stand up and preach how to code to vendors. Sadly, I am only outlining the problem space in hopes that others could step up and run with it. I think it would be appropriate for me to participate in panel discussions at upcoming industry conferences where folks from other verticals could observe the conversation but I wouldn't be permitted to have that type of interaction with vendors as NDA's, code of conduct and other situations would arise. Verisign as an organization has the best characteristics in terms of satisfying this need. Now, it is a matter of whether Verisign truly wants OpenID to be big or whether they are simply dabbling. Promotion could be as simple as putting more information about user-centric approaches on the Verisign homepage. -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 3:18 PM To: McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Promoting OpenID People might be, though nothing real formal that I personally know of. You volunteering? :P --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Monday, April 02, 2007 8:15 AM To: specs@openid.net Subject: Promoting OpenID As an end-user to user-centric approaches, I have noticed an interesting pattern. Microsoft does a wonderful job of selling Cardspace as a solution to others who develop in Microsoft languages. Likewise, there are tons of vendors that can offer solutions for large enterprises to purchase but no one is promoting user-centric approaches to the vendors us large enterprises do business with in terms of getting them to embrace user-centric approaches within their own code base. Sure, we can as consumers raise awareness, but I would like to understand thoughts on other than procurement, how could we make this more pervasive? Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Anders, On 4/3/07, Anders Feder [EMAIL PROTECTED] wrote: Rowan Kerr skrev: The RP can send an update_url to the OP when it fetches the attributes, so it will get new values when the user changes them at the OP. But the RP can't know if the update_url is honored, i.e. if it will ever receive any updates from the OP. Imagine an RP requesting your bank account number X from your OP. Time goes by, and your OP goes out of business. Later, you switch banks and your account number X is assigned to someone else. In the meantime, the RP has been preparing a payment for a job you have done for them. The RP look up your account number in its database, and see X. And since the RP has not received any updates to your bank account information, it reasons that your account number is still X and consequently disburse your payment on a stranger's account ... When I update my information at a new OP how about some way to tell the RP it is the most authoritative. Not sure if this should be taken care of at the application or protocol level, I'd like to see it in the protocol though. The big concern I see with this is that anyone could setup an OP and claim to be the most authoritative source of information. One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. It will happen. I already have plans to share data far more sensitive than bank accounts and have brought the idea up to a few organizations that are at least interested in the concept. So far I have looked at layers of encryption, authorization and authentication on top of OpenID to solve this though. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? Yes, or if the Store request never leaves the OP server, for whatever reason. The OP could tell the user if there was a failure. This way the user can notify the RP or at least be aware of the problem. Not perfect, but it could be treated just like a bounced email or DNS update failure. Wayne -- Phone: 414.208.0808 Learn something from everybody. Some people will teach you what to do, while others will teach you what not to do. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Dick Hardt wrote: There are two common client server design patterns. Request / Response and Publish / Subscribe. I see - I was not aware that the latter model was so well-understood in the client/server paradigm. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. It is, but will automated transactions not make up a significant portion of the communications on the service-oriented Web? * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. I see the merits of user-centricism, but what happens if a user do want an RP to receive an update but the RP is unavailable? For instance, imagine I have ordered a secret product from an RP. Before my order is fully processed, circumstances force me to move to another (postal mail) address. If the connection to the RP is not available when updating my mail address attribute on the OP, for whatever reason, the RP will send the secret package to my old address and whoever lives there now. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. And rightfully so, because the user selects his OP based on his trust that its address structure will not change - this is the key principle in OpenID. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Good point :) In most cases you are probably right, but one can imagine attributes, especially in futuristic scenarios, which are almost inherently 'pull' (like GPS data) such that translating them into 'pushes' are immensely ineffective. But I guess 'push' is per-attribute optional, in that case? information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * The OP must donate storage space to support the distribution of The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. Only if the user actually wish to restrict access - and the RP would not have access to this storage. Anyway, I'm convinced you have thought it through. Pull relates to push as quantum mechanics relates to relativistic physics - but very often quantum mechanics is overkill. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 3, 2007, at 9:14 PM, Wayne Pierce wrote: One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. It will happen. I already have plans to share data far more sensitive than bank accounts and have brought the idea up to a few organizations that are at least interested in the concept. So far I have looked at layers of encryption, authorization and authentication on top of OpenID to solve this though. I'd like to second this. I'm looking at using OpenID in the developing world, in the context of helping communities to transition out of being refugee camps. The hardware is a few years away from being cheap enough to use, but has many billion-dollar companies working on it (cellphones, wimax, etc.) The software, however, is much less well examined, so that's where I'm currently focussing. In these contexts, your OpenID, accessed by your cellphone, may be the hardest identity credential you have - much more trustworthy than your government issued ID, given to you by a state you fled years ago - or the interim credentials your host country provided you with. I should be getting some OSD funding to work on this idea in the next few weeks. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Wayne Pierce wrote: When I update my information at a new OP how about some way to tell the RP it is the most authoritative. Not sure if this should be taken care of at the application or protocol level, I'd like to see it in the protocol though. The big concern I see with this is that anyone could setup an OP and claim to be the most authoritative source of information. I agree completely. Currently, if my OP turns rogue or otherwise fail to serve me, I'm left with no recourse. A bullet-proof way of dealing with this would be with digital signatures though I sense some aversion to PKI in the OpenID community. The OP could tell the user if there was a failure. This way the user can notify the RP or at least be aware of the problem. Not perfect, but it could be treated just like a bounced email or DNS update failure. Yes, this is probably how it will be handled and it will work. I just think there will be corner cases where the user is not able to 'change course' in time. And handling corner cases sets excellent technology apart from very good technology - but it will work. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On 3-Apr-07, at 3:05 PM, Anders Feder wrote: Dick Hardt wrote: There are two common client server design patterns. Request / Response and Publish / Subscribe. I see - I was not aware that the latter model was so well- understood in the client/server paradigm. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. It is, but will automated transactions not make up a significant portion of the communications on the service-oriented Web? * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. I see the merits of user-centricism, but what happens if a user do want an RP to receive an update but the RP is unavailable? The OP can try again later. The reverse would need to be true if the OP was not available when the RP wanted to get the data. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. And rightfully so, because the user selects his OP based on his trust that its address structure will not change - this is the key principle in OpenID. The user can change OPs if they are using delegation. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Good point :) In most cases you are probably right, but one can imagine attributes, especially in futuristic scenarios, which are almost inherently 'pull' (like GPS data) such that translating them into 'pushes' are immensely ineffective. But I guess 'push' is per- attribute optional, in that case? Who has access to my GPS data is something I will want to tightly control! information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * The OP must donate storage space to support the distribution of The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. Only if the user actually wish to restrict access - and the RP would not have access to this storage. I think we all learned the negative aspects of having our data publicly searchable with email and spam. The FOAF camp was rolling along with the Pull model until they realized the issues around access control of the data. Anyway, I'm convinced you have thought it through. Pull relates to push as quantum mechanics relates to relativistic physics - but very often quantum mechanics is overkill. Not sure I follow the analogy. Push is actually much simpler then Pull for any kind of sensitive data, which is most of the useful attribute data. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 3, 2007, at 16:20, Dick Hardt wrote: The FOAF camp was rolling along with the Pull model until they realized the issues around access control of the data. ... Push is actually much simpler then Pull for any kind of sensitive data, which is most of the useful attribute data. I think the archives of the OpenID mailing lists (this one and its predecessor list at Six Apart) are full of endless cycles on the push- vs.-pull argument. Funnily enough, to the best of my knowledge, so far the debate actually hasn't advanced at all since probably more than a year ago. In summary: Push is better because access control is easier and the user always needs to take a specific action to actually move data (i.e. better user control) etc. etc. Pull is better because access control is just as easy (that's what we have OpenID for!), and the only reason we have spam is because it's built on the e-mail push model etc. etc. With a long list of etc. etc. in both cases. I'd prefer if we not go back to this discussion unless somebody has a genuinely new argument. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Web Access Management
Ping demoed OpenID technology at RSA. I hear Novell and IBM are looking at supporting OpenID. Microsoft has said they will in future products. Oracle and CA are following OpenID. So, yes. :-) On 2-Apr-07, at 8:21 AM, McGovern, James F ((HTSC, IT)) wrote: 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 this space to promote OpenID? ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG namespace URI rollback
I can see an OP thinking that AX is a big step, but have a hard time seeing it to be that big for an RP (once there are libraries that support AX) ... and it is really not that much more to do AX over SREG for an RP. Where you thinking OP or RP David? -- Dick On 3-Apr-07, at 12:17 PM, Recordon, David wrote: I see there being a gap between SREG and AX with nothing bridging it. IMHO, AX takes too large of a step for people to use it if they just want a few more SREG fields. I think we need something which does nothing more than provide a way to extend SREG and that will solve the majority of problems today. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, April 02, 2007 7:16 PM To: Recordon, David Cc: Johnny Bufu; OpenID specs list Subject: 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 versus a hard-coded list of properties. -1 SREG works because it's so dead simple. Attribute exchange is not much more complicated, and it lets you specifiy field names with URIs *and* allows you to define any attributes you see fit. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
