W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

RE: Trying to summarise (was Re: DAP and security)

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Thu, 19 Nov 2009 17:14:32 +0100
To: Adam Barth <w3c@adambarth.com>, Robin Berjon <robin@berjon.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>, public-webapps WG <public-webapps@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C28942D75D4@OBEEX01.obe.access-company.com>
>>I don't believe you can design secure APIs by first implementing the
>>APIs and then worrying about security later.
+1
Speaking for myself, in BONDI [1] the most interesting, controversial and complex topics arise when the Interfaces [2] meet Architecture & Security [3,4].
Security requires clarity, i.e. Architecture. Interfaces - to deliver Architecture - require something like API design patterns [5].
The task may be not completed on all fronts, but BONDI tries to deliver all of those components in a consistent manner as required.

Though, it is hard to make a large group work together on all aspects at once.

Thanks,
Marcin

[1] http://bondi.omtp.org/1.1/CR/
[2] http://bondi.omtp.org/1.1/CR/apis/index.html
[3] http://bondi.omtp.org/1.1/CR/security/BONDI_Architecture_and_Security_v1.1_CR.pdf
[4] http://bondi.omtp.org/1.1/CR/security/BONDI_Architecture_and_Security_Appendices_v1.1_CR.pdf
[5] http://bondi.omtp.org/1.1/CR/apis/BONDI_Interface_Patterns_v1.1.html

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Adam Barth
Sent: Thursday, November 19, 2009 4:59 PM
To: Robin Berjon
Cc: public-device-apis@w3.org; public-webapps WG
Subject: Re: Trying to summarise (was Re: DAP and security)

On Thu, Nov 19, 2009 at 3:24 AM, Robin Berjon <robin@berjon.com> wrote:
> Finally, we can all talk about policy and trust in browsers until we're bluer in the face than a hypothermic smurf the fact of the matter is that I don't believe that this is a case where discussion can produce consensus. There are use cases for policy, and solutions for those will be developed at the very least for the widgets landscape. If it so happens that they yield interesting innovative stuff that could be useful in browsers, then it'll be easy to point to it as proof and demo. Far easier than to argue about it, and it'll happen faster if we create the technology rather than talk about it :)

I don't believe you can design secure APIs by first implementing the
APIs and then worrying about security later.  That's the road that
leads to systems like User Account Control (UAC).  Instead, you need
to understand the security requirements up-front and design your APIs
to match.

If you ignore input from browser vendors who've been working with
these issues for years, it's unlikely you'd design something they'll
find palatable.

Adam


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Thursday, 19 November 2009 16:15:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT