On 6/10/10 12:04 PM, "Shaz" <[email protected]> wrote: On Thu, Jun 10, 2010 at 11:59 PM, Janne Karhunen <[email protected]> wrote: >> On Thu, Jun 10, 2010 at 9:39 PM, Shaz <[email protected]> wrote: >> >>>> Do you have in mind a particular use case and risks you wish to protect >>>> against? I can take that example to explain how it can be done by our >>>> framework. >>> >>> Please re-read the use-case again ... you have overly simplified it. >>> Openness between manufacturer and operator is something else while openness >>> with third party service providers is something else and then the policy >>> management between multiple authoritative domains. The third service >>> provider might not come through the operator's authoritative domain? Here >>> the rights cannot be managed at operator's cloud alone! >> >> As I said, we're not generic security kitchen sink and have >> somewhat limited problem to solve. For now, each installation >> source has known set of credentials they can grant. >> > > So you just use the term open while you are restricting the business model! > The user can be fooled but not the community. How do you expect trusted > computing to be used if this is the attitude of designers at Nokia and > whatever? > > Apologies for my school of thought. >
No apologies necessary. I wouldn't leap to conclusions though. We just aren't trying to solve the general security issue but instead are trying to address specific concerns. What we create may be applicable to a broader area though. As for Janne's other comment that didn't make it into your reply, please be a bit patient as we get everything available. Unfortunately, corporations and lawyers don't move as fast as everyone might like. Once we _do_ have everything out there, we would very much appreciate your help! Yes, the TPM/TXT case is well understood. I'm glad you agree on that. :-) Ryan > >> >>> Where does rbac play its role? Credentials ...? >> >> We're not exactly rbac. I take the public arch docs have been >> corrected in this sense already? > > No. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
