Hey Shane, No worries about any "lack of contribution" on Pairsona. We're still very much at the design phase. It's best to know what the heck we're building before we rush off and do anything, particularly since this involves user info and cross team coordination. (I'm also a bit hesitant to say that the comm link is coming together. We've got a few ideas and have made a few experiments, but there are a lot of questions still.)
The Proposal doc <https://docs.google.com/document/d/1_n8IQa7YBymnUE87sYORzc7j-zPwHt9EhOP7RQ1aJ5I/edit#> is my effort to try and resolve a bunch of that, and also to get a start on documentation. If there are areas you feel aren't being addressed, PLEASE add them! A document like that may also help others come up to speed quickly if we have to press others into service. For now, let me present the use case as I understand it. Feel free to point out anything I get wrong, since I'm sure there will be plenty of that: In a general sense, we want to establish a trusted communication channel between a "trusted" device and an "untrusted" device. I've taken to calling these the Authority and Supplicant, since one has something that the other wants. I'm also a bit uncomfortable about hand waving how the actual authority information is exchanged, but that's outside of my direct expertise, and y'all are far smarter about that. I also try to avoid saying what any of these devices are, since that seems to be a bit fluid. It may be that the Authority is a desktop device and the Supplicant is Fenix. It may be that the Authority is a VR headset and the Supplicant is Gecko. Basically, the way I'm thinking is that input may be restricted or difficult on one of the devices where it may not be on the other. We can impose a few base requirements, though, such as devices with limited input must have a reliable alternate input mechanism (e.g. a camera or microphone), the authority must have some compatible means to broadcast (e.g. a screen or speaker), and that both devices must be able to communicate in a compatibly secure means (e.g. OAuth2 Device Flow / *Pake authorized credential exchange / Remote Debugging Auth / Sekkrit Order of the Waterbuffalo handshake). I don't believe we've really come to a consensus about what that will be, and could absolutely use your knowledge about what might be the best to implement on multiple clients. I think you're right on the mark about what we'll need for Fenix <-> desktop. I agree that we're missing UI/UX, and I have no idea if we're going to get something. We may have to settle for the initial version being "Engineer Ugly" and use that as a threat to get some actual skill involved. So, yeah, I've rambled a bit myself, but PLEASE don't feel like you're being ignored or that things are barrelling ahead. There will be lots of time for that once we know what we're doing and where we're going. On Tue, Jul 10, 2018 at 4:07 AM, Shane Tomlinson <stomlin...@mozilla.com> wrote: > Hi JR, Ben, Ryan, Alex, and Julie, > > Pardon my lack of contribution to Pairsona, I am still trying to get Q2 > work wrapped up. I see a lot of work being done to establish communication > links between two devices, thank you all, when I was exploring a couple of > quarters ago that is the portion I felt least confident about. > > Now that the comm link is coming together, I feel like I am a blocker to > making user-facing progress. That lack of progress on my part, and not > knowing what actually needs to be done, leaves me feeling a bit anxious. > > Most of that anxiety comes from not yet having a clear understanding of > the "product" we want to deliver by the end of the quarter, and the > technical components needed to make that product a reality. > > For me it'd be useful if we identified exactly one use case to start with, > think about how we want the UI to look, and determine how that UI maps onto > browser, fxa, and server components. > > In San Francisco, we talked about two use cases: > > 1. Pair Fenix on a phone to desktop > 2. Pair a WebVR headset to a phone or desktop > > Since the first is apparently a blocker to Fenix being released (TBH I > think we should have pushed back on that claim, forcing another team's hand > by claiming "blocker" is a heavy handed tactic), that seems like the > logical place to start. It seems prudent to keep in mind other use cases > and how we can extend our arcitecture to support them, but targeting > exactly one use case to begin will help keep at least me focused. What do > others think? Fenix<->desktop? > > For Fenix<->desktop pairing, my understanding is we'll need: > > 1. A desktop component to get keys out of the browser, possibly some UI > 2. An FxA UI component to pair devices > 3. A communication link between the desktop device and 2nd device > 4. An Android component to accept keys & sessionToken, possibly some UI > > For UI/UX, I don't think much of what I prototyped in Q4 of 2017 will be > usable in a production system, but it's a place to start. Do we have UX > support or are we going to do some Engineer Lead Design? > > For the communication link, have any of the explorations lead to any ideas > of what that protocol should look like once the link is established? > > Now that I'm reading TL;DR requiring lengths, I should close this out. I > personally would like to see us choose one use case, break the work into > more concrete components, take ownership of those components, and progress. > > I reckon this week is still going to be taken up with Q2 work, next week I > can hopefully dig out my old code. > > Thanks, > Shane >
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
