May 2 2007 Meeting notes: Difference between revisions
Joe.andrieu (talk | contribs) |
|||
Line 100: | Line 100: | ||
The challenge remains that when the vendor finds a user. | The challenge remains that when the vendor finds a user. | ||
One option: put the RFP as an Identity-filterable blog post, tag it as a particular type of RFP, ping a clearinghouse, then allow access and comments by selected vendors (hopefully selected as a class of Vendor). | One option: put the RFP as an Identity-filterable blog post, tag it as a particular type of RFP, ping a clearinghouse, then allow access and comments by selected vendors (hopefully selected as a class of Vendor). the structure and usability of such a service *must* be presented and developed in such a way that it is easily integrated into existing software and ops in use by vendors. Acceptance, more so, the ability for vendors to grasp and use the service, is critical to succees. | ||
The choice of response channel should potentially be set by the user, allowing either email-style responses, "comments" on an RFP blog, or some other mechanism. | The choice of response channel should potentially be set by the user, allowing either email-style responses, "comments" on an RFP blog, or some other mechanism. |
Revision as of 13:35, 2 May 2007
Conference Call Notes
Drafted by Joe Andrieu, May 2, 2007
Previous Meeting Links
- February 8
- February 22
- Conference MP3
- No notes available
Attendees
(please update with last names & IM if you'd like a backchannel during the call...)
- Paul Madsen
- Keith Hopper on AIM: hopperomatic
- Ben Laurie
- Joe Andrieu on AIM: jpandrieu
- Leif Chastaine
- Dean Landsman On IRC: deanland On AIM: deanlandsman
- Britt Blaser
- Deborah Schulz
- Chris Carfi
Status
what | who | when | status |
---------- | ---------- | ---------- | ---------- |
open id on wiki | david | no date | |
static website development | doc, dean, joe, chris | no date | |
group blog/RSS to wiki (venus) | doc | no date | up, but only one author |
project VRM definition | doc | 1 week | still working on it |
brainstorm Initiatives | all | ongoing | |
Set up Jabber Host for conference calls | doc | no date | new |
Unfortunately Doc won't be able to join us today.
Joe: remind Dean about transcript.
Report from Brussels
Doc led a session at the Open Identity event last week. Britt took a look at how Liberty Alliance's architecture might help.
One foundation of VRM is the personal RFP, a way for individuals to express their buying desires in a way that vendors can respond directly. Britt sees a personal RFP as an aspect of a person's Identity. That would be put on the web so buyers could find them, analyze them, and discover with them a potential match for what they could provide me. At its basic, the WSF (web services framework) is a way to do just that: provide aspects of identity securely over the Internet.
Liberty Alliance is a standards body for federated identity and identity services.
VRM still needs to define and XML syntax for what this RFP looks like. Some sort of product number, useful meta-data, etc. Some way for users to describe what they want to buy, maximum price, timing on purchase, etc.
The web services is really about moving around that type of identity-centric document.
So, we have schemas that specify, for example, a calendar format that allows people to share calendar data through this framework.
Consider a use case where Alice is specifying the RFP, but Dad is paying for it. This is discussed on the Technology page.
Social Use Cases
The thought of this term triggered some concerns about a data mining case.
Think of gift registries. I'm a Bride or Groom. Where the good is registered in an identity-capable registry. Liberty's People Service enables this to allow access to the invited people without needing a unique account. The relationship specified by the Bride and confirmed upon login could be used by a VRM system to integrate this information, mapping the desires of the bride against, for example the budget constraints of a particular guest (assuming such constraint is also made available via a People Service for the guest).
In an RFP, there are two different pieces of information: what I want and what I'm willing to pay. In a social application, those might be controlled by separate people.
One scenario is that we don't actually need a means to reconcile offered prices, accepted bids, etc. Just a means to engage in a sales conversation.
We need mechanisms for discovering the guests and their price threshold information. People Services can handle that.
Information RFPs
We could also put out RFPs that are inquiries regarding informational needs rather than just purchase criteria.
Thus, the implicit relationship embedded the RFP can provide some interesting services.
Personal Data Silos
The liberty model seems to support this as well. For a movie-list provider, I would define what conditions the provider releases the RFPs or personal data. Some might be public. Others might be restricted.
So how about being able to specify "Movie Services" as a restriction, rather than explicitly as NetFlix or Amazon or BlockBuster.
Ping ID used to provide a similar service. It'd be nice to have a Hoover's or D&B to offer a categorization service for vendors.
Making this available
How do we make this available to the vendor? WHen a user authenticates to the vendor, they wouldn't generally sign in at the vendor, but through an identity provider. So they authenticate, for example, to Google, then go to Amazon. As the user has single-sign-on in, then Amazon uses the SSO to secure information such as shipping or geolocation in the course of the interaction at the web site.
So, Amazon kicks things off by querying an identity search for that users VRM providers they are engaged with (kept track at the identity provider, Google in this case). Amazon gets this list back, filters out inappropriate VRM providers, and sends a query to the chosen VRM provider (perhaps including the user in the process), asking for Joe's RFPs. The VRM provider responds by delivering the RFPs to Amazon. Amazon tries to match the RFP to viable products, making those available to the user.
There are other models where the discovery of the VRM is more distributed. In theory, I could just put the RFP on my blog and let Amazon discover it.
We could perhaps set up a neutral clearinghouse for vendors and users to have a trusted safe place where the user is the arbiter: including syntax and business practices that enable these sorts of transactions.
There needs to be some mechanism for quickly identifying the scope or purpose of an RFP. Vendors should not have to filter every RFP.
The Liberty Model is that the Vendor queries the RFP when the user shows up, rather than trying to scan the entire Internet.
One thing VRM might fix is the problem of finding things. If I could submit an RFP and never have to visit an vendor site.
The challenge remains that when the vendor finds a user.
One option: put the RFP as an Identity-filterable blog post, tag it as a particular type of RFP, ping a clearinghouse, then allow access and comments by selected vendors (hopefully selected as a class of Vendor). the structure and usability of such a service *must* be presented and developed in such a way that it is easily integrated into existing software and ops in use by vendors. Acceptance, more so, the ability for vendors to grasp and use the service, is critical to succees.
The choice of response channel should potentially be set by the user, allowing either email-style responses, "comments" on an RFP blog, or some other mechanism.
We've talked about two extremes, where visiting a vendor triggers the vendor. The other where the user posts the personal RFP on its own. Another alternative is that visiting a site could establish the relationship and then participate in a VRM conversation outside the context of the website.
Tracking quality vendors
There isn't any current way for users to know whether or not a given vendor is a good actor. Reputation is one vehicle for addressing this, but we also perhaps need to establish codes of conduct or rules of engagement that vendors are accountable for, either through reputation, legal recourse, or some other means.
Action Items
what | who | when | status |