DAP Mail List Etiquette? [Was: "Something else"]

Does the DAP WG have any process/guidelines/rules/etc. re mail list  
etiquette? If yes, please send me the pointer(s).

In particular, I'm looking for the recommended mechanism for  
responses, since, with my mailer, some responses are difficult to  
know who said what (see example below); and recommendations on top- 
posting.

-Art Barstow


> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
> Sent: onsdag den 16 december 2009 15:16
> To: Nilsson, Claes1
> Cc: Frederick Hirsch; 'public-device-apis@w3.org'
> Subject: Re: ACTION-38: "Should issue recommendation on the  
> granularity of the security system" + proposal for a "Secure  
> Credential API"
>
> Claes
>
> Thanks for the proposals.
>
> Secure Cred Manager should be deferred to future work.
>
> I have a few questions regarding the "File Granularity Access Policy",
> to help me understand it:
>
> Is it correct to say that the essence of the  "file granularity access
> policy" proposal is to determine an application id from either the X.
> 509 cert or signed widget config, and then pass this application id in
> all API calls?
>
> What value does this add? An example might help me understand the
> benefit.
>
> Claes: I believe there are several use cases.
>
> - An obvious use case is restriction in a file API of access to  
> certain data to certain applications. This is something that is  
> supported by existing application environments.
> - Another example is restriction to "read-only" for certain  
> applications in the file or contacts API
> - And of course, a "Secure credential manager" that I am proposing,  
> is a good example where specific data must be accessible to a  
> specific application only.
> I have added these use cases to an updated version of my proposal  
> that I attach.
>
> Who manages application ids, is there a registry? What prevents any
> widget from including any application id it wants?
>
> Claes: That must be a part of the signing process. The application  
> id could for example be included in a widget's (signed)  
> configuration (assumes some kind of centralized widget signing) or  
> it could be included in the certificate (makes distributed signing  
> possible). I realize that I have been a bit unclear here. An  
> application identity must be relative to the origin of the  
> application, typically the PKI-identity, e.g. the Certificate  
> Authority (CA) of a signed widget's certificate. This means that  
> the CA must coordinate the application identities. So, an AppId  
> actually consists of two parts:
> - Origin of the application, typically the PKI-identity
> - Actual name/id of application
>
> I have updated my description to clarify this at page 6.
>
> What happens in a web case (not widget), where there is no such Id?
> Claes: This is more tricky but I believe that existing security  
> mechanisms such as TLS/SSL can be used. The name/id of application  
> can be included in the server certificate. The weakness here is  
> that we can only verify the server, not the origin of the  
> application. XMLDsig would be another alternative but it is not  
> much used today. Furthermore, this issue exist for any domain based  
> access security system in order to verify the TrustDomain.
>
> What if X.509 certs are not used in certain cases, where does the  
> application id come from?
> Claes: In this case there is no method to securely verify the  
> origin and integrity of the application and the application identity.
>
> Is there an "application id" lifecycle?
> Claes: Have my previous answers clarified this?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia

Received on Saturday, 19 December 2009 14:46:14 UTC