See also: IRC log
<trackbot> Date: 24 February 2010
<fjh> pls Note any additions or changes to agenda
<fjh> Select scribe: http://www.w3.org/2009/dap/victims-list.html
<jmarting_TEF> I kindly would like to ask Mr Chairman if I can join this call
<arve> new name, new scribe, I see :-)
<darobin> gah
<darobin> I never understood what Zakim says, "a customised contrinetics conferencing system"?
<darobin> sorry, thought I was muted
<jmarting_TEF> Yes, that's right. I work for Telefonica. Thanks for letting me to participate
<fjh> claes offers to scribe next time
<fjh> Announcement re BONDI 1.1
<dom> David's announcement of BONDI 1.1 Approved Release
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0074/minutes-2010-02-10.html
RESOLUTION: Minutes 10th Feb approved
<fjh> Use cases & browser-brokering access - http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0109.html
fjh: I'd like to capture this material in one of our documents
<fjh> find api vs input markup : http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0111.html
dom: sure. if we find a way to capture it.
<fjh> default to minimum returned material, none: http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0121.html
fjh: We also need requirements on Privacy. We don't have material on Privacy. People care about this aspect and we need to document it
... Privacy is applicable to all APIs
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0073.html
fjh: Bryan raised questions on OAuth. We can pick it up on the mailing list
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0085.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0089.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0090.html
<drogersuk> Completely agree with you FJH re: privacy
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0093.html
<fjh> bryan argues that policy for authorization can address privacy
Bryan: Wondering whether Privacy is opening a can of worms and whether a good security framework will produce Privacy protection implicitly
fjh: We need to document our actual Privacy requirements in the first instance.
... We need something simple and usable but need to make sure its covered.
drogersuk: Geolocation passed off the privacy issue to DAP so we should not pass it on further
fjh: looking for help to make these privacy requirements concrete
MarkMiller: Powerbox is a concrete proposal that covers the privacy aspect
fjh: We need to understand that better
... in the requirements we don't yet talk about security threats and privacy
<drogersuk> I don't think we should publish for the sake of it
fjh: this will be useful to push towards FPWD. Do we need to do more or use a placeholder for these items?
dom: the requirements document needs some more work before FPWD. We haven't quite framed the scope of what policy framework would be.
<fjh> +1 to dom, personally
<arve> +1 to DOM from here as well
<fjh> suggest we address threats and privacy
dom: We need to do some more work on these areas before we get to FPWD
<darobin> +1 too (I always agree with dom anyway)
<dom> ACTION: Dom to draft something on privacy in policy-reqs [recorded in http://www.w3.org/2010/02/24-dap-minutes.html#action01]
<trackbot> Created ACTION-95 - Draft something on privacy in policy-reqs [on Dominique Hazaël-Massieux - due 2010-03-03].
drogersuk: Outstanding action from OMTP on this aspect.
... we don't want to see FPWD until we've resolved this action
fjh: action is ACTION-45
<fjh> ACTION-45?
<trackbot> ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2010-03-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/OMTP actions/45
<fjh> ACTION-16?
<trackbot> ACTION-16 -- Bryan Sullivan to help review/compare device capabilities and features -- due 2010-02-24 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/16
<fjh> ACTION-48?
<trackbot> ACTION-48 -- Suresh Chitturi to propose a definition for API access control, and a possible model for policy enforcement -- due 2010-02-24 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/48
Bryan: On ACTION-16, something has been posted on the list and more will be coming
<dom> Latest PowerBox draft
darobin: MarkMiller, can you introduce Powerbox?
<dom> Dom's illustration of PowerBox operations
MarkMiller: a lot of the questions in DAP mirror the reasons for producing OAuth
... Personal opinion is that OAuth was a bad solution, but browsers made good solution difficult
... The design principles are the same. The interaction is driven by a requesting site.
<fjh> mark notes delegated access to web resources
<darobin> MM: e.g. Facebook wants your GMail password, but it's not that it wants it, it needs it for access to GMail contacts
<darobin> .... it would be good to only provide the information that you want to provide
MarkMiller: Provide a web site with continued access to your data is the principle.
<darobin> ... but FB doesn't have a way to initiate that interaction
<darobin> .... even with OAuth, the FB page might take you to a phishing page
MarkMiller: How do you know you're interacting with the correct provider? Phishing is possible with OAuth
<darobin> ... the phishing problem is big because it is initiated by the initial site
<darobin> ... but browsers already have a way to handle trustable openings — the file input
<fjh> question - how to specify the granularity of delegated access
<darobin> ... it's an ideal solution to reuse if possible
<darobin> ... remaining important insight is that granting of a file is a direct interaction
<darobin> ... it's a fine grained choice of individual files
<darobin> .... browser can't do that for resources on a site or device
<darobin> ... because it would need to understand the semantics of the service and how it cuts itself up into subresources
<darobin> ... in Powerbox the service can return not just the resource, but an HTML page that can give the user the granularity she needs
<Suresh> yes
<darobin> ... the advantage in terms of security and privacy is that users understand what they're doing [rest garbled from here]
<Zakim> fjh, you wanted to ask about granularity and html
<darobin> MM: OAuth has both a coarseness problem and a trusted path problem
<darobin> FJH had asked about how granularity plays out with HTML
<darobin> MM: also with OAuth, only big players get to play
<darobin> .... eg FB will list Yahoo, GMail, MS Live, but not your local friendly community
Mark_Miller: Powerbox is polymorphic to the provider
... Powerbox only needs a provider of the right type, not any specific provider(s)
<darobin> ... Powerbox can work with anything that the user has set up because they care
<darobin> ... small players find themselves on par with big ones
Mark_Miller: The Powerbox choice dialog is rendered on user's registered Providers
<Zakim> richt, you wanted to ask about use of file input
<darobin> ... and not on just a preselected list
<darobin> richt: it would be great to use input, but it doesn't degrade nicely in browsers that don't support it
<darobin> ... falling back to a file picker is not ideal
<darobin> MM: what is the proposed enhanced interaction that's better than file picker?
<darobin> richt: we were considered relying on JS, could be implemented as a button
<darobin> ... can be implemented easily, but security/privacy maintained
<darobin> ... at this point in time the file picker isn't as great as we'd like it to be
<darobin> MM: had not thought about the degrading issue
<darobin> .... the approach itself is non-blocking
<darobin> ... is there a proposal for a general authorisation/interaction that degrades well to older browsers
<darobin> richt: what the JS approch gives is the ability to check if that exists
<darobin> MM: so the issue is feature testing
<darobin> richt: could be a solution, yes
<darobin> MM: in that case, all we need is something to test
<darobin> ... that could be [garbled, but I presume a navigator.powerbox idea]
<darobin> richt: that could be a mitigating approach
<darobin> MM: it's ridiculous that if I have a pic on flickr now, I have to download it to my drive in order to upload it elsewhere
<darobin> ... here with the file control if it's PB-enabled flickr would be addressable, and the degradation is select from drive
<darobin> richt: ideally the test and the object would be the same thing, but yes this could be a mitigating factor
<darobin> ... we should explore a test
<darobin> MM: I thikn that's a good idea, I'll relay it to the team
drogersuk: How does this sit alongside the JS API work done so far? Supersedes or sits alongside?
MM: I see it as super-seeding
<dom> [I think PowerBox provides two very different aspects: a way to register remote resources providers, and a way to communicate with a resource provider; I'll note that we could use both aspects, or only one of them, or one always and the other sometimes]
MM: Devices as REST services approach does not need abstraction to JS APIs. The common language of these requests is XHR
... Phrasing all devices as XHR interactions you get abstracted in the JS libraries in a way compliant with existing libraries
<fjh> i thought mm said many libraries abstract rest into js calls
MM: REST APIs are abstracted to JS APIs according to existing conventions.
drogersuk: how does Powerbox work with a non-connected device or without a web server?
MM: The device doesn't need an actual web server...
<darobin> (shows an example of XHR requests without the web server)
MM: ...Devices only need to appear to be web services. i.e. you interact via XHR in much the same way as web services
<darobin> drogersuk: are we not just shifting the problem?
drogersuk: Is Powerbox shifting the problem to XHR?
MM: The weakest link shifts to XHR, which is a stronger link, which is better
... No policy framework in the browser to understand a policy framework language.
... Browsers don't have that now.
<darobin> .... have never seen a policy language based on a solid security theory
MM: A user can form a mental model of the risks they are undertaking without a policy framework language
... The only thing they are placing at risk to a requesting site is the things they have selected.
<darobin> MM tells a story about the mental model of users, and how a text editor should only have access to the files they are told to manipulate (as opposed to the whole FS)
drogersuk: User interaction is required with every file that a file manager sees?
MM: No. A directory as a container is a plausible mental model.
<darobin> [in the PB model, the granularity is decided by the service provider]
<darobin> TAHOE
<dom> Tahoe: A Secure Distributed Filesystem
MM: Tahoe provides affordance for being able to provide a directory. It can only provide read access or read/write access to specific files
... e.g. The PowerBox doesn't need to have any knowledge of those choices. The providing site decides on the semantics
<darobin> ... and the access granularity
drogersuk: You're relying on the user to make an intelligent choice
<darobin> ... I don't think that we're a million miles away
<fjh> mm notes providing site has to give choices based on semantics, and do this appropriately
drogersuk: we need to be careful on that approach
MM: Agree. The user doens't want to be faced with lots and lots of choices, just to agree with anything to get their work done.
... This is something we all want to avoid
drogersuk: This comes back to the requirement to have more Privacy and Security Threat discussion included in the Privacy requirements.
<dom> [concrete next steps in forms of action items would be a good outcome of this discussion]
Bryan: For me, the PowerBox proposal fits better in the WebApps group, and is a v2 topic.
<dom> [I disagree that this is not in scope for our group]
Bryan: I think this is a generic web thing and not a device thing
<tlr> [+1 to Dom's disagreement]
<darobin> +10000
<fjh> +1 to Dom, this should be considered
<Claes2> +1 to Dom
MM: Devices being standardised as RESTful provider APIs is the proposed scope of PowerBox
darobin: disagrees with Bryan. This is directly relevant to the DAP WG
... provides much better integration of devices in to the web
Bryan: The concept driving DAP was not such a distributed resource concept. This may have further implications.
... There would be no notion of session or blanket access to the PowerBox?
<tlr> for the record, I believe that using PowerBox to frame device APIs is within the scope of the work here.
Bryan: e.g. I want a resource to be provided on an ongoing basis without further interaction with the Powerbox
MM: A serving site can include the URL to a previously chosen resource to provide continued access in a session manner
<fjh> mm notes mime type and class allows requesting site to say what it wants, provider must interact appropriately based on it. mm notes that dap should provide conventions for this as part of its work, using the powerbox framework
MM: The response is communicated to the Provider and the Provider acts on that to provide access. We could come up with conventions to make the distinctions between one-time access/continued access and read-write/read access.
<AnssiK> [re Powerbox degradation & feature detection: if we were to introduce an attribute unique to PB to <input>, e.g. "pattern" as in Robin's Powerbox walkthough, we'd be able to test whether a certain property exists on an input object and act accordingly, this would be similar to HTML5 feature detection: http://www.modernizr.com/]
MM: Not a fan of XACML. Taken a look at BONDI - seems way over complicated for the DAP problem.
Bryan: We have the need for a seamless less obtrusive UX by acting on the preferences of a user
... so we should not rely on just having a user choosing based on their mental model but to also delegate that choice
MM: What interaction do you provide with the user for them to make informed choices?
Bryan: e.g. I trust AT&T. I trust Yahoo, etc
MM: Want to avoid that at all costs. I don't trust any entity. I trust particular entities with particular things
<dom> [I think this discussion is only highlight different perspectives, not sure it's worth continuing]
Perhaps we could focus on contributions rather than general discussion on trust?
<fjh> then you are back to OAuth if you fully trust a site?
drogersuk: What BONDI is trying to do is delegate to 3rd parties the trust.
... Network operators have a legal liability to consumers and they need to pay attention to this aspect.
<Zakim> dom, you wanted to make his point on the call :)
dom: Thanks Mark and colleagues for this proposal.
<fjh> +1 to thanking Mark and his colleagues
<darobin> dom: there are two aspects in that proposal
<darobin> ... one is how to add providers, the other is how to interact with
<darobin> ... we can use either or both, perhaps different for different APIs
<darobin> dom: thinking in terms of other tabs may have usability/accessibility issues
<fjh> thanks to Bryan and David mentioning issues as well
<darobin> MM: didn't necessarily mean "tab", it can be anything other
MM: The tabbed approach was intented to be illustrative only
... May be other interaction implications
Suresh: What are the implications on performance with the Powerbox approach vs existing direct JS APIs approach?
... Seem to be Security issues that need to be resolved regardless of the approach
... We've done work and how are we going to address the change of direction?
... Are they complimentary, layered, etc?
MM: Performance is constrained to an existing device resources with the overhead of XHR for mediation
Suresh: Currently with the direct APIs we don't see any overhead
MM: They would need to be serialised to be communicated with XHR. Symbolic traffic does not need to be significant.
<dom> [a good exercice would be to re-write the examples in our existing relevant APIs into PowerBox-like interactions]
fjh: we need to understand our choices, look at proposals and work out how it fits together in the coming days/weeks
<dom> [also, I doubt SysInfo would be re-casted into this model?]
fjh: valuable to take a new proposal and consider its applicability to the problem
<Zakim> darobin, you wanted to say that reuse is possible
fjh: ...especially for the long run
darobin: existing work can be used to build the JSON protocols for the Powerbox approach. No strong duplication of effort
<darobin> ACTION: Robin to rewrite exsiting examples as PB [recorded in http://www.w3.org/2010/02/24-dap-minutes.html#action02]
<trackbot> Created ACTION-96 - Rewrite exsiting examples as PB [on Robin Berjon - due 2010-03-03].
darobin: Might not want to push all APIs to the PowerBox approach because it may not have the same privacy considrations. An example might be Sysinfo.
Suresh: Does not want to see an inconsistent approach: part JS APIs / part REST. Security would become difficult, using two paradigms..
... would like to continue work on what we have and work out if we can converge in the coming weeks
<maxf> or we could go REST 100%, even sysinfo. I'll think about it.
Bryan: when we look at serialize/unserialize it's not just a small amount of data. Sometimes theres a lot of data and that could affect performance. Need to consider other cases such as getting multiple contacts.
<dom> [Bryan makes a good point on the amount of data serialization/de-serialization]
darobin: Any other action items to discuss on Powerbox?
drogersuk: I can lay out abuse cases around widgets. We could compare how BONDI and PowerBox would compare in handling those abuse cases
<dom> ACTION-45?
<trackbot> ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2010-03-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/45
drogersuk: will lay out e.g. phishing scenarios and we can compare the approaches. Can indicate how BONDI addresses, Mark can cover Powerbox
drogersuk: BONDI 1.1 introduces a number of updates to improve the overall quality of the initiative
<fjh> David requests that this be added as submission to home page of DAP.
drogersuk: At Mobile World Congressimplementations of BONDI were demoed.
... WAC announcement also good for W3C DAP
<darobin> phew, long call :)
<darobin> thanks richt, you picked your week to minute!
<fjh> Much thanks Richard for scribing!!