Re: CfC: Policy Framework FPWD

James

I'm not sure what you are suggesting, but I think it is along the lines of "merge XACML profile back into framework document" and "create a provisioning document". If so, the WG already decided to make the XACML profile separate, so unless we have new information, we should not revisit that decision.

If you have something else in mind it might be clearer if you note the rough outline for the various documents.

Regarding provisioning, it is out of scope, especially with respect to policies:

"The management of security policies (e.g. by remote entities) is out of scope of this group."

In general, an end-to-end solution is appropriate to privacy, security etc. For example, considering all aspects, business, legal, regulatory, CA operation, certificate distribution, key management, provisioning, etc etc.  We cannot do all this, so yes our scope is limited to an aspect of the system.  Not much to do about that, though in some sense it makes the work of the WG that harder while also giving us  a chance to finish.

What we can do is recognize the critical aspects about what we do that relate to other system touch points. If you have any ideas please share them on the list.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group




On Jun 16, 2010, at 11:37 AM, ext James Salsman wrote:

> On Tue, Jun 15, 2010 at 6:39 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
>> ...
>> * there should be somewhere presumably a reference to the XACML profile doc
> 
> How do people feel about merging the XACML profile into a combined
> Device API Policy Framework Profile document, adding examples to it,
> and then extracting out the algorithms including the issues
> surrounding modeless one-at-a-time prompting and other authorization
> actions (e.g. camera shutter button -- are there any other examples?)
> into a new Device API Policy Permissions and Provisioning document?
> The former would focus on the data structures, and the latter on the
> algorithms.  I think if we are going to try to define security
> certificate-based remote permissions that would be a much better
> approach.
> 
> Now I see that provisioning isn't in scope per charter, but I can't
> figure out where it is in scope.  If we have to define privacy state
> information but aren't allowed to say anything about how defaults are
> set, then there are serious quality issues which will arise with the
> specifications.
> 
> Do we need to get permission from someone who is allowed by their
> charter to discuss initial and enterprise default provisioning?
> 
>> ** the document doesn't have a conformance section....
> 
> I agree there should be one, at least reiterating the "must"
> statements elsewhere.
>

Received on Wednesday, 16 June 2010 22:07:14 UTC