W3C home > Mailing lists > Public > public-web-intents@w3.org > August 2012

RE: Passing "origin" with intents

From: Josh Soref <jsoref@rim.com>
Date: Wed, 29 Aug 2012 17:12:30 +0000
To: WebIntents <public-web-intents@w3.org>
Message-ID: <957F1ECDA90E004B8DBDE23CFC94E3A33A52AA56@XMB103ECNC.rim.net>
Matthew wrote: 
> IMHO, we don't want the user making a choice to disclose origin or not. It will
> be difficult to communicate the concept of "origin" to a user. I think that most
> users would not be able to understand the implications of disclosing the origin,
> so giving them this choice seems like it wouldn't really accomplish anything
> other than force an uncomfortable choice on the user.

There will probably COTS products which will be meant for in house systems, like Zimbra and Github and Mailman. They will probably (if they're maintained) eventually grow Intent support. And users will want to use them. But ...

Let's look at a Zimbra deployed for a company "Example.com Inc." It has an internal client system "Client Referrals", for some reason they want to know if people were using the corporate Zimbra for Pick-Contact, so they want this "origin" property. As such, they can't configure zimbra.example.com's Pick-Contact provider *not* to supply a "return" origin. However, when the user wants to run an app "Facebook", and it asks the user to Pick-Contact, and the user selects zimbra.example.com, the user doesn't want to leak `zimbra.example.com` with the selected Contact.

Now, that example is backwards, for a `service reply origin` as opposed to a `client request origin`.

I'm sure there are use cases (specifically the Auth/O-Auth stuff), but I'd like to see a UC described in terms of something else, a Pick-*, or similar.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Wednesday, 29 August 2012 17:13:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC