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 21:56:29 +0000
To: WebIntents <public-web-intents@w3.org>
Message-ID: <957F1ECDA90E004B8DBDE23CFC94E3A33A52B436@XMB103ECNC.rim.net>
Greg wrote:
> Talking separately to some people interested in using intents as an
> IPC mechanism, having 'origin' on explicit intents (my suggestion 4
> above) would satisfy their needs.

> Would this also satisfy the use case of making Oauth-style authentication?

> If so, perhaps we should limit
> 'origin' to that for the time being -- it's seems fair that an
> explicit intent carry the origin of the requester, since it is
> directed at a specific service anyway.

This seems /less/ problematic. I'd have to work through some cases.

One case is:
Github.example.com with an explicit "pull-request" intent to github.com or something like that.

In the case I know of, github as a software thing is licensed by github.com to example.com, and thus already knows about this instance so this isn't a secret that needs preserving.

I could imagine a company wanting to have a way for their employees to "tweet this" from an internal site "super-marketing.example.com", where it /might/ not want twitter to know that it's in fact being crowd-sourced by super-marketing, however that company could of course use a custom client which ignores this part of the specification. Offhand, breaking this specific example(/requiring a non conformant UA) doesn't bother me. I don't have the time today to figure out whether there are other cases where the origin has a real right-to-privacy if it's using an explicit intent.

So, call this a "tentative-ok-by-me".

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 21:57:03 UTC

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