Comments on: ProtectServe: getting down to (use) cases http://www.xmlgrrl.com/blog/2009/03/29/protectserve-getting-down-to-use-cases/ Tangled musings on identity, privacy, trust, and suchlike Sat, 08 Oct 2011 19:31:02 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Eve M. http://www.xmlgrrl.com/blog/2009/03/29/protectserve-getting-down-to-use-cases/comment-page-1/#comment-231112 Eve M. Wed, 29 Apr 2009 14:31:56 +0000 http://www.xmlgrrl.com/blog/?p=856#comment-231112 Hi Joe-- Great observations! I had considered personal RFPs as a Hey, Sailor type of use case, but hadn't gone very far down the road of imagining how much data would have to be released as a "taste" (which does release some personal data into the wild for free, so to speak). The service-endpoint piece you describe could be generic ProtectServe, if we take the lessons of this use case (along with all the others) properly in further design work. For example, we'd been envisioning that meeting the terms of a contract may be more than the Consumer just saying "I agree to the contract" - it may require providing positive claims, like "here's the receipt for the money you require to be paid to see your data". The offering to Sailors might or might not advertise the data format in which the offered data is encoded, but standard data formats are, I think, important for making an ecosystem of this sort powerful and generative. Content negotiation could perhaps be used in delivering data in a form the Sailor/Consumer could handle, though the simplest thing would be to have a personal RFP format. (<a href="http://cyber.law.harvard.edu/projectvrm/VRM2008_Phil_and_Paul_get_married_(BT)" rel="nofollow">This</a> was one proposed example.) Simple and RESTful is good, in my book, and I hope we can use the power of resources and URLs and content types in getting this going. Hi Joe– Great observations! I had considered personal RFPs as a Hey, Sailor type of use case, but hadn’t gone very far down the road of imagining how much data would have to be released as a “taste” (which does release some personal data into the wild for free, so to speak).

The service-endpoint piece you describe could be generic ProtectServe, if we take the lessons of this use case (along with all the others) properly in further design work. For example, we’d been envisioning that meeting the terms of a contract may be more than the Consumer just saying “I agree to the contract” – it may require providing positive claims, like “here’s the receipt for the money you require to be paid to see your data”.

The offering to Sailors might or might not advertise the data format in which the offered data is encoded, but standard data formats are, I think, important for making an ecosystem of this sort powerful and generative. Content negotiation could perhaps be used in delivering data in a form the Sailor/Consumer could handle, though the simplest thing would be to have a personal RFP format. (This was one proposed example.) Simple and RESTful is good, in my book, and I hope we can use the power of resources and URLs and content types in getting this going.

]]> By: Joe Andrieu http://www.xmlgrrl.com/blog/2009/03/29/protectserve-getting-down-to-use-cases/comment-page-1/#comment-231059 Joe Andrieu Wed, 29 Apr 2009 09:37:46 +0000 http://www.xmlgrrl.com/blog/?p=856#comment-231059 I like the "Hey Sailor" variant, with perhaps more specific late binding as to the data transaction being offered. All that you need to advertise is enough information to attract the right Sailor, you don't need to specify the data. For example, I don't have to say "Hey Sailor, want my vCard?" You can say "Hey Sailor, I'm looking to buy a baby stroller. Interested?" In other words, the publication can be a request for services, independent of the data transaction, which could be negotiated later. To be concrete, like posting a link to a personal RFP to Twitter with a hashtag #prfp. "I'm looking for a baby stroller in Minneapolis ASAP. http://bit.ly/fe2f33 #prfp" This is close to Hey Sailor, but doesn't specify the data type. It publishes the service endpoint for discovering the data options, with a tag indicating who might be interested (sailors selling baby strollers near Minneapolis, presumably). That service endpoint (http://bit.ly/fe2f33) would handle the data transaction, including authentication and moderating the scope or availability of information based on same, e.g., offering credit references or real-time geo data to approved Sailors. The call for Sailors need not be specific to a particular piece of data, such as a vCard or iCal. I like the “Hey Sailor” variant, with perhaps more specific late binding as to the data transaction being offered. All that you need to advertise is enough information to attract the right Sailor, you don’t need to specify the data. For example, I don’t have to say “Hey Sailor, want my vCard?” You can say “Hey Sailor, I’m looking to buy a baby stroller. Interested?”

In other words, the publication can be a request for services, independent of the data transaction, which could be negotiated later. To be concrete, like posting a link to a personal RFP to Twitter with a hashtag #prfp. “I’m looking for a baby stroller in Minneapolis ASAP. http://bit.ly/fe2f33 #prfp”

This is close to Hey Sailor, but doesn’t specify the data type. It publishes the service endpoint for discovering the data options, with a tag indicating who might be interested (sailors selling baby strollers near Minneapolis, presumably).

That service endpoint (http://bit.ly/fe2f33) would handle the data transaction, including authentication and moderating the scope or availability of information based on same, e.g., offering credit references or real-time geo data to approved Sailors. The call for Sailors need not be specific to a particular piece of data, such as a vCard or iCal.

]]> By: Pushing String » ProtectServe draft protocol flows http://www.xmlgrrl.com/blog/2009/03/29/protectserve-getting-down-to-use-cases/comment-page-1/#comment-225247 Pushing String » ProtectServe draft protocol flows Thu, 02 Apr 2009 23:06:53 +0000 http://www.xmlgrrl.com/blog/?p=856#comment-225247 [...] previous posts I’ve described the basic ProtectServe/Relationship Manager proposition and use cases. Here is a set of web protocol flows we’ve developed to support our goals. This design is [...] [...] previous posts I’ve described the basic ProtectServe/Relationship Manager proposition and use cases. Here is a set of web protocol flows we’ve developed to support our goals. This design is [...]

]]> By: Brian Hawthorne http://www.xmlgrrl.com/blog/2009/03/29/protectserve-getting-down-to-use-cases/comment-page-1/#comment-224985 Brian Hawthorne Wed, 01 Apr 2009 19:26:29 +0000 http://www.xmlgrrl.com/blog/?p=856#comment-224985 "What sort of girl does he think customers are?" We've already established what sort of girl they are. Your protocol is all about haggling over the price. I suppose that makes RMs really Personal Information Management Programs. “What sort of girl does he think customers are?”

We’ve already established what sort of girl they are. Your protocol is all about haggling over the price. I suppose that makes RMs really Personal Information Management Programs.

]]> By: links for 2009-03-30 • Bare Identity http://www.xmlgrrl.com/blog/2009/03/29/protectserve-getting-down-to-use-cases/comment-page-1/#comment-224531 links for 2009-03-30 • Bare Identity Tue, 31 Mar 2009 00:00:58 +0000 http://www.xmlgrrl.com/blog/?p=856#comment-224531 [...] Pushing String » ProtectServe: getting down to (use) cases (tags: vrm protectserve evemaler) [...] [...] Pushing String » ProtectServe: getting down to (use) cases (tags: vrm protectserve evemaler) [...]

]]>