RE: Passing "origin" with intents

Why couldn’t the browser just send the client origin whenever it is different from the service origin, similar to how it decides to send the Origin header?

Thanks,
Bryan Sullivan

From: James Hawkins [mailto:jhawkins@google.com]
Sent: Monday, August 27, 2012 9:10 AM
To: Greg Billock
Cc: Conrad Irwin; public-web-intents@w3.org
Subject: Re: Passing "origin" with intents

The key thing to keep in mind is that exposing the client's origin is a decision that must be left to the client.

We could say that the client must pass its origin through the payload, but the service can't trust that data; consequently, that means the browser must pass the origin to the service.  I think we're in agreement that there are compelling use cases for this addition, so now we must figure out how the client tells the browser to send its origin.  Any ideas?

James

On Sun, Aug 26, 2012 at 9:19 PM, Greg Billock <gbillock@google.com<mailto:gbillock@google.com>> wrote:
We've discussed this, but there's no formal proposal yet. Do you want
to draw one up? Certainly for explicit intents this seems like it'd be
a good addition.

With an origin to establish an out-of-band shared secret, you can do
Oauth-style flows. Without it, you can do OpenId type flows where you
basically get a warrant that the bearer controls some namespaced
token.



On Sun, Aug 26, 2012 at 7:32 PM, Conrad Irwin <conrad.irwin@gmail.com<mailto:conrad.irwin@gmail.com>> wrote:
> Hi all,
>
> I saw some earlier mention [1] of the inability for web-intents to
> obtain the origin of the calling site.
>
> Is this something that will be added?
>
> I am also working on an authentication protocol; and without the
> ability to verify the origin of a message, WebIntents are almost
> useless. (I can work around it by making the call to the intent from a
> content-script running in my chrome extension that shares a secret
> with the intent; but that feels very fragile).
>
> A couple of other use-cases for including the origin could be:
> • Content-filtering: If I am running an image sharing web-intent, I
> might want to block content from http://*.xxx.
> • UI enhancement: If I am running an editing web-intent, it would be
> nice to be able to tell the user "return to <origin>"
> • Authentication: If I am running an authentication web-intent, it's
> essential to know which website is asking for the user's identity (I
> don't want to give it to a malicious 3rd-party by accident).
>
> Conrad
>
> [1] http://lists.w3.org/Archives/Public/public-web-intents/2012May/0012.html

>