RE: ACTION-38: "Should issue recommendation on the granularity of the security system" + proposal for a "Secure Credential API"

Hi Frederick,

I am not sure that I completely understand your question but I interpret it so that you have an issue with coordination of application identities. Step 3 in the flow on page 6 in the "Fine Granularity Policy Based Device Access Security" presentation tries to clarify this. An application identity (AppId) consists of two parts:
- Origin of the application, typically the PKI-identity
- Actual name/id of application

So the application's name/id is relative to the origin of the application. This means that the CA must coordinate the application names/ids within it's root chain. If for example a company provides web applications that need to access device APIs that are restricted to the actual application identities then this company needs to coordinate the application identities within each root chain of this company's CA.

Does this clarify?

Claes



> -----Original Message-----
> From: Frederick Hirsch [mailto:Frederick.Hirsch@nokia.com]
> Sent: torsdag den 31 december 2009 17:47
> 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 clarifying the message.
> 
> It looks like application id is  acting like role or group - this
> almost seems on the path toward attribute certificates and the related
> infrastructure.
> 
> I'm still not sure I understand how this would integrate in practice
> on a web without centralized authority - perhaps ignored unless
> understood?
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Dec 21, 2009, at 5:30 AM, ext Nilsson, Claes1 wrote:
> 
> > Hi,
> >
> > Sorry if my previous post was difficult to follow due to missing
> > indentations. Hope this is clearer :-)
> >
> > Frederick,
> >
> > See my answers inline below and an updated version of "Fine
> > granularity access policy".
> >
> > Claes
> >
> > > -----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?
> >
> > Claes:
> > Correct
> > >
> > > 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
> > document (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 also for verifying 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
> > >
> > >
> > >
> > > On Dec 15, 2009, at 5:15 AM, ext Nilsson, Claes1 wrote:
> > >
> > > > Hi,
> > > >
> > > > I attach two proposals:
> > > >
> > > > 1.       "File granularity access policy". This is response to my
> > > > action 38. The proposal is based on "Policy Based Device Access
> > > > Security" (Steve Lewontin/Nokia
> > > http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/att-
> > > 0012/SecurityPolicy_09.pdf)
> > > >  that Steve presented at the Santa Clara meeting. My proposal
> > adds a
> > > > finer granularity to restrict access to APIs based on application
> > > > identity.
> > > > 2.       "Secure Cred Manager". This proposal is based on 1 above
> > > > and is an API for retrieving securely stored data,
> > "credentials", in
> > > > the device. A major use case for this API is Social Networking
> > > > Services web application application login to the service. I
> > have a
> > > > humble view on this and understand the security issues with
> > > > JavaScript. However, by referencing existing security mechanisms
> > > > such as Digital signing, TLS/SSL and WARP, I believe that such an
> > > > API is possible. Furthermore, I realize that it is not possible
> to
> > > > include this API in the phase 1 delivery from DAP but I want to
> > have
> > > > it in the list of "Future Work".
> > > >
> > > > Best regards
> > > >   Claes
> > > > Claes Nilsson M.Sc.E.E
> > > > Senior Staff Engineer
> > > > CTO - R&T Europe - UI/App/Web
> > > >
> > > > Sony Ericsson Mobile Communications
> > > >  Phone:  +46 10 80 15178
> > > > Mobile: +46 705 56 68 78
> > > > Switchboard: +46 10 80 00000
> > > > E-Mail: mailto:claes1.nilsson@sonyericsson.com
> > > > Visiting Address; Nya Vattentornet
> > > > SE-221 88 LUND,
> > > > Sweden
> > > > Disclaimer:
> > > > The information in this e-mail is confidential and may be legally
> > > > privileged. It is intended solely for the named recipient(s) and
> > > > access to this e-mail by anyone else is unauthorized. The views
> > are
> > > > those of the sender and not necessarily the views of Sony
> Ericsson
> > > > and Sony Ericsson accepts no responsibility or liability
> > whatsoever
> > > > or howsoever arising in connection with this e-mail.Any
> > > > attachment(s) to this message has been checked for viruses, but
> > > > please rely on your own virus checker and procedures. If you
> > contact
> > > > us by e-mail, we will store your name and address to facilitate
> > > > communications. If you are not the intended recipient, please
> > inform
> > > > the sender by replying this transmission and delete the e-mail
> and
> > > > any copies of it without disclosing it.
> > > >
> > > >
> > > > <Secure Cred Manager.pptx><File granularity access policy.pptx>
> >
> > <Fine granularity access policy.pptx>

Received on Tuesday, 12 January 2010 11:18:24 UTC