<div dir="ltr"><div>Yea, there's plenty of nasties involved with storing and serving user files. We'll provide a mix of "you already have a thing? we'll use that!" and "you don't have a thing? we can give you one!".<br>

<br></div>Here though, I'm talking about the process of connecting *any* attached service to your Firefox account, and what that looks like.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 3:43 PM, JR Conlin <span dir="ltr"><<a href="mailto:jrconlin@mozilla.com" target="_blank">jrconlin@mozilla.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Huh, this is an interesting problem space for a lot of reasons, and I<br>
think we might benefit from a lot of the discoveries that other similar<br>
services have made in the past.<br>
<br>
Consider that for delivery of avatars, we're effectively creating a CDN.<br>
That means taking image data and storing it to lots of different servers<br>
so that it can be served up quickly. That also means that you'll need to<br>
consider how accessible "replaced" avatars might be (e.g. are they<br>
replaced immediately, or are older avatars eventually removed? What<br>
should happen if a user points directly to a resolved image? Should we<br>
munge images such that folks can't use it as a warez storage system<br>
(yes, they'll do that, ask folks at <a href="http://del.icio.us" target="_blank">del.icio.us</a> and facebook about<br>
that)? etc.)<br>
<br>
I think that akamai may have useful resources around some of these,<br>
although as I remember, they focus on rapid push and eventual takedown.<br>
<br>
The nice thing is that the server would effectively be a large 302<br>
service so that should make things a bit easier.<br>
<div class="im"><br>
On 2014/2/4 3:31 PM, Sean McArthur wrote:<br>
> The first part of this puzzle is how we connect attached services to a<br>
> Firefox Account. Any consumer (desktop, Marketplace, etc) will be<br>
> requesting that a user be signed in with Firefox Accounts, along with<br>
> some additional profile data about the user. What does this look like?<br>
><br>
> I'm imagining a consumer does (if its not <a href="http://navigator.id" target="_blank">navigator.id</a><br>
</div>> <<a href="http://navigator.id" target="_blank">http://navigator.id</a>>, then insert proper API):<br>
<div class="im">><br>
>   navigator.id.request({<br>
>     attached: [ '<a href="https://profiles.accounts.firefox.com#avatar" target="_blank">https://profiles.accounts.firefox.com#avatar</a>' ]<br>
>   })<br>
><br>
> This signals to Firefox Accounts that it also needs some attached data,<br>
> identified by a URI. The auth-server would need to discover and/or fetch<br>
> related information, probably prompting the user for permission to do<br>
> so, and then bundling it in the assertion in `idpClaims` (or its<br>
> equivalent).<br>
><br>
> Does this seem sound? I imagine wanting to specify an API that this<br>
> follows, so any attached service can be used. An RP could conceivably<br>
> create some new attached services, and request them using `attached: [<br>
> '<a href="https://myservice.anrp.com#data" target="_blank">https://myservice.anrp.com#data</a>' ]`.<br>
><br>
><br>
</div>> _______________________________________________<br>
> Dev-fxacct mailing list<br>
> <a href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/dev-fxacct" target="_blank">https://mail.mozilla.org/listinfo/dev-fxacct</a><br>
><br>
<br>
</blockquote></div><br></div>