June 20 2007 Meeting notes - Revision history

Joe.andrieu: /* Other Calls */

2007-07-25T17:21:21Z

Other Calls

← Older revision		Revision as of 17:21, 25 July 2007
Line 6:		Line 6:

	==Other Calls==		==Other Calls==
	[[Category:conference call~~\|2007 06 20~~]]		[[Category:conference call]]
	[[:Category:conference call]]		[[:Category:conference call]]

Joe.andrieu: Meeting notes 2007 06 20 moved to June 20 2007 Meeting notes

2007-07-25T17:21:02Z

Meeting notes 2007 06 20 moved to June 20 2007 Meeting notes

← Older revision	Revision as of 17:21, 25 July 2007
(No difference)

Joe.andrieu: /* Prior Calls */

2007-07-25T17:06:18Z

Prior Calls

← Older revision		Revision as of 17:06, 25 July 2007
Line 5:		Line 5:
	#vrm at chat.freenode.net		#vrm at chat.freenode.net

	==~~Prior~~ Calls==		==Other Calls==
	[[conference call ~~archive~~]]		[[Category:conference call\|2007 06 20]]
			[[:Category:conference call]]

	==Attendees==		==Attendees==

Joe.andrieu: /* Notes */

2007-06-20T19:02:45Z

Notes

@@ Line 29: / Line 29: @@
 # Best practices: getting people together to learn together how to solve real world problems and drive market adoption further and faster.
-The dashboard is a meme whose time has come. There was a privacy dashboard post. There was another one that was more general.  This should become a standard feature; it would be consistent with models like Higgens. SUch that a personal Higgens service would be exposed via a dashboard.  There are some technical details... how do the pieces talk to each other. Then there is a need for a standard interoperable implementation, much like apache helps drive/stabilize web standards. Finally, there still needs to be policy layer interoperability. That is, the controls on the dashboard need to map to the controls offered by the different vendors. If there isn't a match it doesn't work.
+The dashboard is a meme whose time has come. There was a privacy dashboard post. There was another one that was more general.  This should become a standard feature; it would be consistent with models like Higgins. Such that a personal Higgins service would be exposed via a dashboard.  There are some technical details... how do the pieces talk to each other. Then there is a need for a standard interoperable implementation, much like apache helps drive/stabilize web standards. Finally, there still needs to be policy layer interoperability. That is, the controls on the dashboard need to map to the controls offered by the different vendors. If there isn't a match it doesn't work.
 So, what we actually need is to standardize and get interoperability at the policy layer as well.
-Higgens and Sxipper. Higgens is open source. Sxipper is a proprietary application. They both use the identity meta-system, but one is an open, multi-vendor solution the other is a product. Both are solutions for personal data services.  Higgins is middle-ware that will accommodate different protocols. Sxipper may not have that same design goal.
+Higgins and Sxipper. Higgins is open source. Sxipper is a proprietary application. They both use the identity meta-system, but one is an open, multi-vendor solution the other is a product. Both are solutions for personal data services.  Higgins is middle-ware that will accommodate different protocols. Sxipper may not have that same design goal.
 Sxipper has great ease of use with great details about what one chooses to share. Four different identity types ready to share.  OnePassword, which is locally-based single-sign on of sorts. It's an elegant password-centric tool.
@@ Line 91: / Line 91: @@
 One way to circumvent that may be to find the Vendor's killer app, where they don't or can't get the data today, but which could be created in the personal data store. That's sort of what Google Checkout is doing.  There are millions of long-tail vendors out there who don't want to manage shopping carts and transaction management. Instead, they'll use PayPal or GoogleCheckout.  There must be a vendor killer app that could bypass this challenge of changing vendor's data hording habits.
 ==Status==

Joe.andrieu: /* Notes */

2007-06-20T18:37:26Z

Notes

← Older revision		Revision as of 18:37, 20 June 2007
Line 58:		Line 58:

	In some ways, this sounds a lot like Google checkout. This does perform this intermediary service, where it shares only a limited set of information with the vendor.		In some ways, this sounds a lot like Google checkout. This does perform this intermediary service, where it shares only a limited set of information with the vendor.

			Many of these vendors are already implementing aspects of these services, but in a closed service.


			Are there particular stumbling blocks?

			The problem is that everyone rolls their own. Google, MSN, Yahoo!, AOL.

			Given that there are these silo reactions, what is the common thing that they want to protect?

			We have to show that their adoption is going to ease their customer acquisition process more than it will lead to customer attrition.

			Which leads to the fact that they want all that data to do their marketing.

			Show some grass roots momentum. So that if they don't, their partners are going to do it.

			Also, look at Privacy International. There will be continued pressure from regulatory and markets. We have to hope that this will also help drive adoption.

			There is also a huge problem with crafting a shared language between vendors. Establishing a shared lexicon is inherently slower than just building the code. So even vendors who like this sort of thing, have a faster route to market building it themselves.

			Many vendors believe their own product is "magic" and often overlook the simplest users. Often the refrain is "but everyone knows how to..." How much of this needs to be couched to the average Jane & Joe? Will the large monolith even think this?

			One concept that we've been promoting is that if there is trust established, then a big part of the job is already done.

			User experience is critical to this, and the large vendors often deal with that at the tail-end of the implementation. So, if we solve that problem, it has a lot of options. And if we can package it in terms of killer apps, then we can cross the gap and get traction. For example, CardSpace packages a killer app for the WS* protocol stack.

			That is, the app drives adoption of the infrastructure. Until we had websites that matters, http and html were irrelevant.

			Demystification... early adopters are far more sophisticated that Joe six pack. But the interesting thing is that when we eventually get to Joe six-pack, it is critical to demystify the product. The interesting thing is that we know that there is an incoming generation that is net-native--extremely comfortable with digital tech. Yet, at the same time the fastest growing online segment is 55-74. (As the boomers age.) These individuals actually have some financial power. They spend money. It is critical to see this appeal to them. A great deal of what Dean does is "demystify" these sites. Getting web developers to use "normal" language to talk with "everyday" users.

			A lot of companies (vendors) are asking for this information, because they always have... this is the basis of how they perceive the world.

			One way to circumvent that may be to find the Vendor's killer app, where they don't or can't get the data today, but which could be created in the personal data store. That's sort of what Google Checkout is doing. There are millions of long-tail vendors out there who don't want to manage shopping carts and transaction management. Instead, they'll use PayPal or GoogleCheckout. There must be a vendor killer app that could bypass this challenge of changing vendor's data hording habits.

	==Status==		==Status==

Joe.andrieu: /* Notes */

2007-06-20T18:16:49Z

Notes

← Older revision		Revision as of 18:16, 20 June 2007
Line 17:		Line 17:

	==Notes==		==Notes==
			===Standards & Practices===
			What is VRM? It is VRM if...

			The issues that have been hot on the mailing list are the privacy dashboard and users as the point of integration. Standards and Practices combines these two.

			One of the technical groups at Liberty came out of a workshop in April for user consent in e-government applications and they are working on a dashboard for e-gov applications.

			Three dimensions:
			# Technical normative standards which any implementor can implement.
			# Interoperability standards so that you have some assurance
			# Best practices: getting people together to learn together how to solve real world problems and drive market adoption further and faster.

			The dashboard is a meme whose time has come. There was a privacy dashboard post. There was another one that was more general. This should become a standard feature; it would be consistent with models like Higgens. SUch that a personal Higgens service would be exposed via a dashboard. There are some technical details... how do the pieces talk to each other. Then there is a need for a standard interoperable implementation, much like apache helps drive/stabilize web standards. Finally, there still needs to be policy layer interoperability. That is, the controls on the dashboard need to map to the controls offered by the different vendors. If there isn't a match it doesn't work.

			So, what we actually need is to standardize and get interoperability at the policy layer as well.

			Higgens and Sxipper. Higgens is open source. Sxipper is a proprietary application. They both use the identity meta-system, but one is an open, multi-vendor solution the other is a product. Both are solutions for personal data services. Higgins is middle-ware that will accommodate different protocols. Sxipper may not have that same design goal.

			Sxipper has great ease of use with great details about what one chooses to share. Four different identity types ready to share. OnePassword, which is locally-based single-sign on of sorts. It's an elegant password-centric tool.

			Avant browser also offered this sort of thing. Firefox also.

			Password management is the very tip of the iceberg for automating the user interaction.

			If we look at form-fillers, etc. OnePassword is pretty good. It encrypts it, works across browsers. But with VRM, we have protocols that are identity-aware. So the problem with Sxipper is that is perpetuates the transfer of identity for transactions. Such that vendors track you as your attributes. But we don't really need to send those attributes--we need the resulting trust that they create.

			I don't want to have to re-enter my information all the time. But that is feeding a lot of information and trust, and responsibility on that tool. Having interactions on the web should not require the user to reveal all this data.

			Does the party need to collect the data about me?

			What about deliver via a clearinghouse so that the vendor doesn't need to know the address.

			The vendor doesn't actually care about password management. So we can release that. The same thing can be true of the attributes, such as shipping address. If they could hand-off that information management task to a third party, then the vendor is minimizing costs.

			One challenge is this data is that this data is used for multiple purposes. It isn't just a matter of shipping. Companies often use the data for marketing analysis. So, the question is how can we allow these more abstract post-sale functionalities without busting the privacy bubble.

			In a web services scenario where all of these pieces are being done on behalf of the user, you can have the releases automated at the point of service.

			Someone mentioned a Vodafone demo that implemented an address functionality through UPS that allowed delivery without the initial vendor knowing the address.

			In some ways, this sounds a lot like Google checkout. This does perform this intermediary service, where it shares only a limited set of information with the vendor.

	==Status==		==Status==

Joe.andrieu: /* Attendees */

2007-06-20T17:41:35Z

Attendees

← Older revision		Revision as of 17:41, 20 June 2007
Line 14:		Line 14:
	* Brett McDowall		* Brett McDowall
	* Drummond Reed		* Drummond Reed
			* Keith Hopper

	==Notes==		==Notes==

Joe.andrieu: /* Attendees */

2007-06-20T17:40:26Z

Attendees

← Older revision		Revision as of 17:40, 20 June 2007
Line 13:		Line 13:
	* Mark Lazar		* Mark Lazar
	* Brett McDowall		* Brett McDowall
			* Drummond Reed

	==Notes==		==Notes==

Joe.andrieu: /* Attendees */

2007-06-20T17:35:27Z

Attendees

← Older revision		Revision as of 17:35, 20 June 2007
Line 12:		Line 12:
	* Dean Landsman		* Dean Landsman
	* Mark Lazar		* Mark Lazar
			* Brett McDowall

	==Notes==		==Notes==

Joe.andrieu: /* Attendees */

2007-06-20T17:34:04Z

Attendees

← Older revision		Revision as of 17:34, 20 June 2007
Line 11:		Line 11:
	* Joe Andrieu		* Joe Andrieu
	* Dean Landsman		* Dean Landsman
			* Mark Lazar

	==Notes==		==Notes==