14:22:06 RRSAgent has joined #dap 14:22:06 logging to http://www.w3.org/2010/02/24-dap-irc 14:22:08 RRSAgent, make logs world 14:22:08 Zakim has joined #dap 14:22:10 Zakim, this will be DAP 14:22:10 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 38 minutes 14:22:11 Meeting: Device APIs and Policy Working Group Teleconference 14:22:11 Date: 24 February 2010 14:25:02 Chair: Robin_Berjon, Frederick_Hirsch 14:26:49 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0138.html 14:35:49 Dzung_Tran has joined #dap 14:35:58 Present+ Dzung_Tran 14:36:11 Present+ Robin_Berjon, Frederick_Hirsch 14:46:45 Topic: Welcome, agenda review, scribe selection 14:46:59 pls Note any additions or changes to agenda 14:47:08 Select scribe: http://www.w3.org/2009/dap/victims-list.html 14:48:58 Regrets: Marcin_Hanclik 14:53:33 UW_DAP()10:00AM has now started 14:53:35 + +39.011.228.aaaa 14:53:51 marengo has joined #dap 14:54:29 zakim, aaaa is marengo 14:54:29 +marengo; got it 14:54:46 Present+ Jesus_Martin 14:54:52 Present+ Marco_Marengo 14:54:56 Zakim, mute me 14:54:56 sorry, marengo, muting is not permitted when only one person is present 14:55:27 I kindly would like to ask Mr Chairman if I can join this call 14:55:30 new name, new scribe, I see :-) 14:55:40 + +0472369aabb 14:55:41 - +0472369aabb 14:55:41 + +0472369aabb 14:56:01 zakim, aabb is me 14:56:01 +maxf; got it 14:56:05 (I think) 14:56:10 +[IPcaller] 14:56:33 Zakim, mute me 14:56:33 marengo should now be muted 14:56:39 +[IPcaller.a] 14:56:47 zakim, [IPcaller.a] 14:56:47 I don't understand '[IPcaller.a]', fjh 14:56:55 zakim, [IPcaller.a] is fjh 14:56:55 +fjh; got it 14:57:00 zakim, who is here? 14:57:00 On the phone I see marengo (muted), maxf, [IPcaller], fjh 14:57:00 zakim, who is making noise? 14:57:01 On IRC I see marengo, Dzung_Tran, Zakim, RRSAgent, fjh, jmarting_TEF, arve, tlr, maxf, Marcos, ilkka, trackbot, dom 14:57:11 arve, listening for 10 seconds I heard sound from the following: [IPcaller] (11%), fjh (19%) 14:57:23 zakim, [IPcaller] is arve 14:57:23 +arve; got it 14:57:24 AnssiK has joined #dap 14:58:14 Present +Max Froumentin 14:58:21 Present+ Arve Bersvendsen 14:58:24 Present + Max Froumentin 14:58:35 Present+ Max Froumentin 14:58:51 + +035850486aacc 14:58:59 zakim, aacc is me 14:58:59 +AnssiK; got it 14:59:01 +??P32 14:59:20 darobin has joined #dap 14:59:31 zakim, P32 is drogers 14:59:31 sorry, fjh, I do not recognize a party named 'P32' 14:59:37 drogersuk has joined #dap 14:59:53 present+ David_Rogers 15:00:01 zakim, ??P32 is drogers 15:00:01 +drogers; got it 15:00:02 Present+ Anssi_Kostiainen 15:00:08 zakim, who is here? 15:00:08 On the phone I see marengo (muted), maxf, arve, fjh, AnssiK, drogers 15:00:10 On IRC I see drogersuk, darobin, AnssiK, marengo, Dzung_Tran, Zakim, RRSAgent, fjh, jmarting_TEF, arve, tlr, maxf, Marcos, ilkka, trackbot, dom 15:00:12 +[IPcaller] 15:00:20 Zakim, [IPCaller is me] 15:00:20 +me]; got it 15:00:24 gah 15:00:35 Zakim, [IPCaller] is me 15:00:35 sorry, darobin, I do not recognize a party named '[IPCaller]' 15:00:43 Zakim, me] is me 15:00:43 +darobin; got it 15:01:02 LauraA has joined #dap 15:01:02 Claes has joined #dap 15:01:23 + +358.504.86aadd 15:01:29 Present+ Claes_Nilsson 15:01:32 zakim, aadd is me 15:01:33 +ilkka; got it 15:01:42 zakim, who is making noise? 15:01:46 I never understood what Zakim says, "a customised contrinetics conferencing system"? 15:01:49 +Dom 15:01:50 zakim, mute me 15:01:52 Bryan has joined #dap 15:01:55 + +0777541aaee 15:01:59 +Bryan_Sullivan 15:02:01 Dom should now be muted 15:02:05 fjh, listening for 10 seconds I could not identify any sounds 15:02:05 Present+ Dominique_Hazael-Massieux 15:02:14 zakim, who is making noise? 15:02:21 zakim, +0777541aaee is LauraA 15:02:23 +LauraA; got it 15:02:27 fjh, listening for 10 seconds I could not identify any sounds 15:02:34 Present+ Ilkka_Oksanen 15:02:44 zakim, who is making noise? 15:02:54 fjh, listening for 10 seconds I heard sound from the following: 11 (15%) 15:03:00 sorry, thought I was muted 15:03:27 zakim, who is here? 15:03:27 On the phone I see marengo (muted), maxf, arve (muted), fjh, AnssiK, drogers, darobin, ilkka, Dom (muted), LauraA, Bryan_Sullivan 15:03:30 On IRC I see Bryan, Claes, LauraA, drogersuk, darobin, AnssiK, marengo, Dzung_Tran, Zakim, RRSAgent, fjh, jmarting_TEF, arve, tlr, maxf, Marcos, ilkka, trackbot, dom 15:03:33 + +46.1.08.01.aaff 15:04:15 Yes, that's right. I work for Telefonica. Thanks for letting me to participate 15:04:53 richt has joined #dap 15:05:09 + +04610715aagg 15:05:17 +Ingmar_Kliche 15:05:20 zakim, aagg is Niklas 15:05:26 +Niklas; got it 15:05:26 + +0208849aahh 15:05:40 nwidell has joined #dap 15:05:41 + +03491482aaii 15:05:47 + +34.91.337.aajj 15:05:49 claes offers to scribe next time 15:05:52 Present+ Niklas_Widell 15:06:03 Present+ Robin_Berjon 15:06:12 Present+ Bryan_Sullivan 15:06:39 Ingmar has joined #dap 15:06:57 Present+ LauraA 15:07:24 Suresh has joined #dap 15:07:40 Present+ Suresh_Chitturi 15:07:41 Announcement re BONDI 1.1 15:08:01 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0144.html David's announcement of BONDI 1.1 Approved Release 15:08:01 regrets - will be late by 30mins to join the audio bridge! 15:08:15 RuthVazquez has joined #dap 15:08:29 richt has joined #dap 15:08:34 zakim, aajj is me, Jesus Martin 15:08:34 I don't understand 'aajj is me, Jesus Martin', jmarting_TEF 15:08:48 Zakim, aajj is jmarting_TEF 15:08:48 +jmarting_TEF; got it 15:08:56 sorry made a mistake 15:09:39 akim, aaii is me, Jesus Martin. Now it is correct 15:09:52 Topic: Minutes Approval 15:10:12 http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0074/minutes-2010-02-10.html 15:10:14 RESOLUTION: Minutes 10th Feb approved 15:10:25 TOPIC: Policy 15:10:51 Use cases & broswer-brokering access - http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0109.html 15:11:21 s/brosw/brows/ 15:11:22 ack me 15:11:28 fjh: I'd like to capture this material in one of our documents 15:11:49 find api vs input markup : http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0111.html 15:11:51 dom: sure. if we find a way to capture it. 15:11:53 zakim, call thomas-781 15:11:53 ok, tlr; the call is being made 15:11:55 +Thomas 15:12:00 default to minimum returned material, none: http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0121.html 15:12:03 + +1.408.615.aakk 15:12:04 zakim, I am thomas 15:12:04 ok, tlr, I now associate you with Thomas 15:12:06 zakim, mute me 15:12:06 Thomas should now be muted 15:12:12 Present+ Thomas_Roessler 15:12:26 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 15:12:33 present+ Ingmar_Kliche 15:12:59 fjh: Privacy is applicable to all APIs 15:13:04 q+ 15:13:14 zakim, aakk is probably MarkMiller 15:13:14 +MarkMiller?; got it 15:13:36 http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0073.html 15:13:39 fjh: Bryan raised questions on OAuth. We can pick it up on the mailing list 15:14:09 http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0085.html 15:14:26 http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0089.html 15:14:36 http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0090.html 15:14:45 q? 15:14:47 ack Bryan 15:14:56 Completely agree with you FJH re: privacy 15:15:02 http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0093.html 15:15:32 bryan argues that policy for authorization can address privacy 15:15:36 Bryan: Wondering whether Privacy is opening a can of worms and whether a good security framework will produce Privacy protection implicitly 15:16:02 fjh: We need to document our actual Privacy requirements in the first instance. 15:16:36 fjh: We need something simple and usable but need to make sure its covered. 15:16:48 q- 15:17:04 drogersuk: Geolocation passed off the privacy issue to DAP so we should not pass it on further 15:17:14 RuthVazquez has joined #dap 15:17:22 fjh: looking for help to make these privacy requirements concrete 15:17:47 MarkMiller: Powerbox is a concrete proposal that covers the privacy aspect 15:18:01 fjh: We need to understand that better 15:18:46 fjh: in the requirements we don't yet talk about security threats and privacy 15:19:00 I don't think we should publish for the sake of it 15:19:06 fjh: this will be useful to push towards FPWD. Do we need to do more or use a placeholder for these items? 15:19:18 q+ 15:19:22 ack me 15:19:55 dom: the requirements document needs some more work before FPWD. We haven't quite framed the scope of what policy framework would be. 15:20:13 +1 to dom, personally 15:20:21 +1 to DOM from here as well 15:20:26 suggest we address threats and privacy 15:20:35 dom: We need to do some more work on these areas before we get to FPWD 15:20:36 +1 too (I always agree with dom anyway) 15:20:55 q+ 15:20:57 ACTION: Dom to draft something on privacy in policy-reqs 15:20:57 Created ACTION-95 - Draft something on privacy in policy-reqs [on Dominique Hazaël-Massieux - due 2010-03-03]. 15:21:01 zakim, mute me 15:21:01 Dom should now be muted 15:21:07 ack drogersuk 15:21:21 drogersuk: Outstanding action from OMTP on this aspect. 15:21:39 drogersuk: we don't want to see FPWD until we've resolved this action 15:21:57 ACIONT-45? 15:21:59 fjh: action is ACTION-45 15:22:04 ACTION-45? 15:22:04 ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2010-03-10 -- OPEN 15:22:04 http://www.w3.org/2009/dap/track/actions/45 15:22:10 s/action/OMTP action/ 15:22:29 ACTION-16? 15:22:29 ACTION-16 -- Bryan Sullivan to help review/compare device capabilities and features -- due 2010-02-24 -- PENDINGREVIEW 15:22:29 http://www.w3.org/2009/dap/track/actions/16 15:23:00 ACTION-48? 15:23:00 ACTION-48 -- Suresh Chitturi to propose a definition for API access control, and a possible model for policy enforcement -- due 2010-02-24 -- PENDINGREVIEW 15:23:00 http://www.w3.org/2009/dap/track/actions/48 15:23:16 Bryan: On ACTION-16, something has been posted on the list and more will be coming 15:23:23 rvazquez has joined #dap 15:23:29 Topic: APIs 15:23:48 Topic: Powerbox discussion 15:24:30 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0140/Overview.html Latest PowerBox draft 15:24:55 darobin: MarkMiller, can you introduce Powerbox? 15:25:21 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0148.html Dom's illustration of PowerBox operations 15:25:31 MarkMiller: a lot of the questions in DAP mirror the reasons for producing OAuth 15:25:50 MarkMiller: Personal opinion is that OAuth made the browser difficult 15:26:16 zakim, who is here? 15:26:16 On the phone I see marengo (muted), maxf, arve (muted), fjh, AnssiK, drogers, darobin, ilkka, Dom (muted), LauraA, Bryan_Sullivan, +46.1.08.01.aaff, Niklas, Ingmar_Kliche, 15:26:17 s/Personal opinion is that OAuth made the browser difficult/Personal opinion is that OAuth was a bad solution, but browsers made good solution difficult/ 15:26:19 ... +0208849aahh, +03491482aaii, jmarting_TEF (muted), Thomas (muted), MarkMiller? 15:26:21 On IRC I see rvazquez, RuthVazquez, richt, Suresh, Ingmar, nwidell, Bryan, Claes, LauraA, drogersuk, darobin, AnssiK, marengo, Dzung_Tran, Zakim, RRSAgent, fjh, jmarting_TEF, arve, 15:26:24 ... tlr, maxf, Marcos, ilkka, trackbot, dom 15:26:32 MarkMiller: The design principles are the same. The interaction is driven by a requesting site. 15:26:39 mark notes delegated access to web resources 15:27:19 MM: e.g. Facebook wants your GMail password, but it's not that it wants it, it needs it for access to GMail contacts 15:27:35 .... it would be good to only provide the information that you want to provide 15:27:46 MarkMiller: Provide a web site with continued access to your data is the principle. 15:27:52 ... but FB doesn't have a way to initiate that interaction 15:28:25 .... even with OAuth, the FB page might take you to a phishing page 15:28:26 MarkMiller: How do you know you're interacting with the correct provider? Phishing is possible with OAuth 15:28:35 -drogers 15:29:01 drogersuk has joined #dap 15:29:05 +??P1 15:29:06 Present+ Mark_Miller 15:29:08 ... the phishing problem is big because it is initiated by the initial site 15:29:44 ... but browsers already have a way to handle trustable openings — the file input 15:30:18 question - how to specify the granularity of delegated access 15:30:29 ... it's an ideal solution to reuse if possible 15:30:43 ... remaining important insight is that granting of a file is a direct interaction 15:30:51 ... it's a fine grained choice of individual files 15:31:05 .... browser can't do that for resources on a site or device 15:31:31 ... because it would need to understand the semantics of the service and how it cuts itself up into subresources 15:31:57 ... in Powerbox the service can return not just the resource, but an HTML page that can give the user the granularity she needs 15:31:59 + +1.972.373.aall 15:32:26 q+ to ask about granularity and html 15:32:39 zakim, aall is probably suresh 15:32:39 +suresh?; got it 15:32:45 yes 15:32:52 ... the advantage in terms of security and privacy is that users understand what they're doing [rest garbled from here] 15:32:58 q+ to ask about use of file input 15:33:10 q+ 15:33:16 q+ 15:33:59 ack fjh 15:33:59 fjh, you wanted to ask about granularity and html 15:33:59 q? 15:34:32 MM: OAuth has both a coarseness problem and a trusted path problem 15:34:47 FJH had asked about how granularity plays out with HTML 15:35:00 MM: also with OAuth, only big players get to play 15:35:19 .... eg FB will list Yahoo, GMail, MS Live, but not your local friendly community 15:35:23 Mark_Miller: Powerbox is polymorphic to the provider 15:35:39 Mark_Miller: Powerbox only needs a provider of the right type, not any specific provider(s) 15:35:45 ... Powerbox can work with anything that the user has set up because they care 15:36:01 ... small players find themselves on par with big ones 15:36:15 Mark_Miller: The Powerbox choice dialog is rendered on user's registered Providers 15:36:20 q? 15:36:38 ack richt 15:36:38 richt, you wanted to ask about use of file input 15:36:42 ... and not on just a preselected list 15:37:07 richt: it would be great to use input, but it doesn't degrade nicely in browsers that don't support it 15:37:17 ... falling back to a file picker is not ideal 15:37:26 -arve 15:37:33 MM: what is the proposed enhanced interaction that's better than file picker? 15:37:59 richt: we were considered relying on JS, could be implemented as a button 15:38:20 ... can be implemented easily, but security/privacy maintained 15:38:35 ... at this point in time the file picker isn't as great as we'd like it to be 15:38:41 +arve/marcos 15:38:47 MM: had not thought about the degrading issue 15:38:54 .... the approach itself is non-blocking 15:39:11 ack me 15:39:15 -jmarting_TEF 15:39:22 ... is there a proposal for a general authorisation/interaction that degrades well to older browsers 15:39:41 richt: what the JS approch gives is the ability to check if that exists 15:39:47 MM: so the issue is feature testing 15:39:54 richt: could be a solution, yes 15:40:03 MM: in that case, all we need is something to test 15:40:31 ... that could be [garbled, but I presume a navigator.powerbox idea] 15:40:37 richt: that could be a mitigating approach 15:41:23 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 15:42:03 ... here with the file control if it's PB-enabled flickr would be addressable, and the degradation is select from drive 15:42:28 richt: ideally the test and the object would be the same thing, but yes this could be a mitigating factor 15:42:42 ... we should explore a test 15:42:43 q? 15:43:03 MM: I thikn that's a good idea, I'll relay it to the team 15:43:12 ack drogersuk 15:43:33 drogersuk: How does this sit alongside the JS API work done so far? Supersedes or sits alongside? 15:43:40 MM: I see it as super-seeding 15:43:42 [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] 15:43:45 zakim, mute me 15:43:45 Dom should now be muted 15:44:07 q+ dom to make his point on the call :) 15:44:20 MM: Devices as REST services approach does not need abstraction to JS APIs. The common language of these requests is XHR 15:44:49 MM: Phrasing all devices as XHR interactions you get abstracted in the JS libraries in a way compliant with existing libraries 15:44:55 i thought mm said many libraries abstract rest into js calls 15:45:06 MM: REST APIs are abstracted to JS APIs according to existing conventions. 15:45:25 drogersuk: how does Powerbox work with a non-connected device or without a web server? 15:45:38 MM: The device doesn't need an actual web server... 15:45:39 -> http://dev.w3.org/2009/dap/docs/lrest/gallery-lrest.html (shows an example of XHR requests without the web server) 15:46:28 MM: ...Devices only need to appear to be web services. i.e. you interact via XHR in much the same way as web services 15:46:31 +jmarting_TEF 15:46:54 -arve 15:47:03 q+ 15:47:11 Present+ Jesus_Martin_Garcia 15:47:21 drogersuk: are we not just shifting the problem? 15:47:23 drogersuk: Is Powerbox shifting the problem to XHR? 15:47:35 MM: The weakest link shifts to XHR 15:47:56 s/shifts to XHR/shifts to XHR, which is a stronger link, which is better/ 15:48:09 Claes1 has joined #dap 15:48:41 MM: No policy framework in the browser to understand a policy framework language. 15:48:50 Browsers don't have that now. 15:49:03 .... have never seen a policy system based on a solid security theory 15:49:11 s/system/language 15:49:15 A user can form a mental model of the risks they are undertaking without a policy framework language 15:49:53 s/A user can form/MM: A user can form 15:50:40 s/Browsers don't have that now./MM: Browsers don't have that now. 15:51:08 MM: The only thing they are placing at risk to a requesting site is the things they have selected. 15:51:13 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) 15:51:35 q? 15:51:39 drogersuk: User interaction is required with every file that a file manager sees? 15:52:09 MM: No. A directory as a container is a plausible mental model. 15:52:15 [in the PB model, the granularity is decided by the service provider] 15:52:43 TAHOE 15:52:57 -> http://allmydata.org/~warner/pycon-tahoe.html Tahoe: A Secure Distributed Filesystem 15:53:37 MM: Tahoe provides affordance for being able to provide a directory. It can only provide read access or read/write access to specific files 15:54:30 MM: e.g. The PowerBox doesn't need to have any knowledge of those choices. The providing site decides on the semantics 15:54:40 ... and the access granularity 15:54:57 drogersuk: Relying on the user to make an intelligent choice 15:55:07 ... I don't think that we're a million miles away 15:55:08 mm notes providing site has to give choices based on semantics, and do this appropriately 15:55:11 s/Relying/You're relying 15:55:35 Claes2 has joined #dap 15:55:40 drogersuk: we need to be careful on that approach 15:56:02 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. 15:56:08 MM: This is something we all want to avoid 15:56:31 q? 15:56:37 drogersuk: This comes back to the requirement to have more Privacy and Security Threat discussion included in the Privacy requirements. 15:56:43 blassey has joined #dap 15:57:11 [concrete next steps in forms of action items would be a good outcome of this discussion] 15:57:11 Bryan: For me, the PowerBox proposal fits better in the WebApps group. 15:57:29 s/group/group, and is a v2 topic/ 15:57:51 [I disagree that this is not in scope for our group] 15:57:57 Bryan: I think this is a generic web thing and not a device thing 15:58:01 [+1 to Dom's disagreement] 15:58:16 +10000 15:58:22 +1 to Dom, this should be considered 15:58:40 +1 to Dom 15:58:43 MM: Devices being standardised as RESTful provider APIs is the proposed scope of PowerBox 15:59:04 darobin: disagrees with Bryan. This is directly relevant to the DAP WG 15:59:05 -Thomas 15:59:21 darobin: provides much better integration of devices in to the web 16:00:10 q? 16:00:11 Bryan: The concept driving DAP was not such a distributed resource concept. This may have further implications. 16:00:13 ack Bryan 16:00:35 Bryan: There would be no notion of session or blanket access to the PowerBox? 16:00:55 for the record, I believe that using PowerBox to frame device APIs is within the scope of the work here. 16:01:23 MM: e.g. I want a resource to be provided on an ongoing basis without further interaction with the Powerbox 16:01:42 s/MM: e.g. I/Bryan: e.g. I 16:03:03 MM: A serving site can include the URL to a previously chosen resource to provide continued access in a session manner 16:04:49 mm notes mime type and class allows requesting site to say what it wants, provider must interact appropriately based on it. dap should provide conventions for this as part of its work, using the powerbox framework 16:05:00 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. 16:05:01 s/dap/mm notes that dap 16:05:21 [re Powerbox degradation & feature detection: if we were to introduce an attribute unique to PB to , 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/] 16:05:38 Mark: Not a fan of XACML. Taken a look at BONDI - seems way over complicated for the DAP problem. 16:05:48 s/Mark: Not/MM: Not 16:06:56 Bryan: We have the need for a seamless less obtrusive UX by acting on the preferences of a user 16:07:26 Bryan: so we should not rely on just having a user choosing based on their mental model but to also delegate that choice 16:07:45 MM: What interaction do you provide with the user for them to make informed choices? 16:07:58 Bryan: e.g. I trust AT&T. I trust Yahoo, etc 16:08:03 q+ 16:08:22 MM: Want to avoid that at all costs. I don't trust any entity. I trust particular entities with particular things 16:08:47 [I think this discussion is only highlight different perspectives, not sure it's worth continuing] 16:08:50 q- 16:10:13 Perhaps we could focus on contributions rather than general discussion on trust? 16:10:16 then you are back to OAuth if you fully trust a site? 16:10:40 ack drogersuk 16:11:43 drogersuk: What BONDI is trying to do is delegate to 3rd parties the trust. 16:12:03 drogersuk: Network operators have a legal liability to consumers and they need to pay attention to this aspect. 16:12:11 ack dom 16:12:12 dom, you wanted to make his point on the call :) 16:12:25 dom: Thanks MArk for this proposal. 16:12:40 s/MArk for this/Mark and colleagues for this 16:13:11 dom: How do you interact with resource providers? 16:13:20 +1 to thanking Mark and his colleagues 16:13:25 s/dom: How do you interact with resource providers?// 16:13:31 dom: there are two aspects in that proposal 16:13:43 ... one is how to add providers, the other is how to interact with 16:14:06 ... we can use either or both, perhaps different for different APIs 16:14:25 dom: thinking in terms of other tabs may have usability/accessibility issues 16:14:33