Also a bit of a quick scheduling follow-up: It's been my experience that pushing back on unreasonable demands works best if you can show how unreasonable a demand is. Thus another reason having a good, hard doc is kinda useful.
On Tue, Jul 10, 2018 at 9:57 AM, JR Conlin <jcon...@mozilla.com> wrote: > 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
