Query from UWA about POWDER (was Re: scribe needed for today's call)

Hi Rotan,

I hope you don't mind me shifting this to our public lists (I can't post 
to your member list and this looks like something we should address in 
public anyway).

Rotan Hanrahan wrote:
[..]

> According to the POWDER primer, certification of DRs is indicated in
> order to elevate trust in descriptions.
> 
> Who is proposed to provide/manage such certifications? Would this be the
> current SSL cert providers, for example?

Well, anyone can and they can do it any way they wish. We have been 
careful not to mandate a particular method and certainly not a type of 
organisation.

> 
> If so, who says that these providers are qualified to assess/create
> descriptions?

The end user is the only person that can decide whether they trust a 
claim. I would trust Mobile Aware to certify assertions made by others 
about mobile-related services but I would probably give more weight to 
my brother's opinion [1] if the subject matter turned to modern art.

> 
> Or is the issue of the environment in which certification is managed
> considered out of scope for the POWDER WG?

I guess 'out of scope' is one way of expressing it - there are far too 
many variables for us to try and tie down a single paradigm for trust. 
As we say: "By its very nature, trust is a human judgement that can only 
be made by weighing the likelihood that the data is true against the 
consequences of it being false. This judgement is highly dependant on 
the circumstances under which the need to extend trust arises. POWDER 
does, however, provide support for, and is amenable to, a variety of 
methods through which users and user agents can establish trust."

And we do provide hooks for various methods of which certification is 
just one.

> 
> The question was raised internally within my company when someone
> observed that this might be the creation of another "money making
> scheme", as some people believe the SSL cert providers have been given a
> license to print money.

Well, if someone can make a business out of certifying Description 
Resources, that's no bad thing IMO, however, to reiterate the point, 
certification is not the only method by which trust may be added to a 
DR. If a POWDER document is fetched from a server operated by a 
company/brand I trust and it seems at least unlikely that the data has 
been corrupted between there and my UA then I'll trust it, certified or 
not.

Several POWDER WG members are part of an EU project called Quatro [2] 
that is predicated on DR publishers providing authentication systems 
over SOAP for their DRs (yes, SOAP-POWDER :-)). No 3rd party required 
and so on.

> 
> Comments and clarifications welcome.
> 
> (Otherwise, we find POWDER intriguing, though we wonder what is meant by
> "use of arbitrary RDF in POWDER documents" in the recent request for
> feedback.)

OK, so we need to clarify that wording. The issue is whether we restrict 
the expressivity of POWDER docs a little for the sake of increased 
processing efficiency. All our examples include simple RDF triples that 
have literal values or point to external resources meaning that you can 
process them effectively with just an XML tool kit. If we allow more 
complex RDF (er, that's the arbitrary RDF bit) then a POWDER Processor 
would need to include an RDF tool kit as well. All our use cases tend 
towards the simple solution so we're really looking for an application 
of POWDER (not POWDER-S which is RDF/OWL anyway) where being able to 
express more complex graphs is justified (my gut feeling is that we 
won't but that's what public consultation is for of course).

HTH

Phil.

[1] http://www.ruskin-sch.ox.ac.uk/People/staff_detail.php?id=0
[2] http://www.quatro-project.org/

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Register now for the annual Family Online Safety Institute Conference 
and Exhibition, December 11th, 2008, Washington, DC.
See http://www.fosi.org/conference2008/

Received on Thursday, 28 August 2008 13:54:52 UTC