The biquitous requirements
Download
Report
Transcript The biquitous requirements
Security and Services in
Mobiquitous Computing
Tim Finin
University of Maryland,
Baltimore County
Mobiquitous ’04, 24 August 2004
tell
register
http://ebiquity.umbc.edu/v2.1/event/html/id/45/
Joint work with Anupam Joshi, Yun Peng, Scott Cost & many students.
tell
register
http://creativecommons.org/licenses/by-nc-sa/2.0/
This work was partially supported by DARPA contract F30602-97-1-0215, NSF
grants CCR007080 and IIS9875433 and grants from IBM, Fujitsu and HP.
1
The Question
Is the service model right
for Mobiquitous computing?
UMBC
an Honors University in Maryland
2
The biquitous requirements
The biquitous part of the Mobiquitous vision
often (typically?) assumes or requires:
(1) An open, heterogeneous and dynamic
environment
(2) A high degree of cooperation
(3) Context sensitive functionality
(4) Personalization driven by user models
and data
(5) AI like capabilities
UMBC
an Honors University in Maryland
3
My Answer
The service view is very appropriate
We can’t do all this stuff on a cell phone
or wearable computer
Even if we could, we need to interact with
the other entities in the environment
Ensuring security, privacy and trust is
challenging in this environment and
requires new ideas.
UMBC
an Honors University in Maryland
4
The biquitous requirements
(1) An open, heterogeneous and
dynamic environment
Hosts, devices and people in motion
The context is constantly changing
Reasonable to model these as
autonomous, self-interested agents
Unreasonable to expect unique ontologies
(data models) for most domains.
UMBC
an Honors University in Maryland
5
The biquitous requirements
(2) A high degree of cooperation
Devices are simple but many tasks are
complex – we will want to compose
simple functions and services to
accomplish our objectives
Tasks may also require interaction (e.g.,
negotiation) between requester and
provider
Devices can fill multiple roles (requester
UMBC
an Honors University in Maryland
6
The biquitous requirements
(3) Context sensitive functionality
Context can include location, time,
ongoing activities, user’s intent, etc.
This adds to the dynamism
And raises issues of recognition,
anticipation and adaptation
That requires lots of information, some of
which can only come from other entities
in the environment
UMBC
an Honors University in Maryland
7
The biquitous requirements
(4) Personalization
User profiles and models are a common
theme
We want the environment to recognize or
anticipate our interests, desires and
preferences
This gives rise to many privacy issues
UMBC
an Honors University in Maryland
8
The biquitous requirements
(5) AI like capabilities
The pervasive environment will be (we think)
large and complex, so we shouldn’t assume
the end use will manage it all
Desirable components (e.g., speech, NLP,
vision, etc) are very sophisticated
This has been there from the start, e.g., the
Enterprise bridge, Mark Weiser’s seminal paper
and in Apple’s Knowledge Navigator advert
While this is a project for generations, the
incremental results will pay for the work.
UMBC
an Honors University in Maryland
9
How do we approach this?
Services are a good near term
approach
New approaches to security, privacy
and trust are required
Other components are needed, or at
least useful
UMBC
an Honors University in Maryland
10
Services are a good approach
What do we mean by services?
Not just uddi/wsdl/soap but also agent services, RMI
services, etc.
We need approaches that allow published APIs
and protocols with “semantic” information
This will best support automated discovery,
evaluation, composition, invocation and
monitoring
We require much more than syntactic
interoperability – it’s not just about plumbing
OWL and OWL-S are good starts
UMBC
an Honors University in Maryland
11
Security, trust and privacy
In
an open, dynamic and heterogeneous
environment we must interact with agents
we’ve never met before
This happens at all levels of the stack: ad
hoc networking, P2P, services
Knowing their identity is also not enough
We will have to make decisions based on
verifiable attributes, endorsements,
delegation of trust, etc.
Reputation is a promising approach
UMBC
an Honors University in Maryland
12
Other components
We make heavy use of software agents and
semantic web languages
Agents provide a powerful process abstraction
Underlying BDI model
Rich agent communication languages
Semantic web languages provide an expressive
knowledge sharing language
Designed for community development, use
and maintenance
Supported by practical, open standards
UMBC
an Honors University in Maryland
13
The Celebrity Couple
Semantic
Web
Software
Agents
In 2002, Geek Gossip gushed “The semantic web will
provide content for internet agents, and agents will make the
semantic web “come alive”. Looks like a match made in
Heaven!”
UMBC
an Honors University in Maryland
14
TAGA: Travel Agent Game inOwlAgentcities
for
Owl for
protocol
contract
Features
Technologies
Ontologies
descriptionhttp://taga.umbc.edu/ontologies/
enforcement
Open Market Framework
FIPA (JADE, April Agent Platform)
Motivation
Market dynamics
Auction theory (TAC)
Semantic web
Agent collaboration (FIPA &
Agentcities)
Owl for
modeling
trust
Auction Services
OWL message content
OWL Ontologies
Global Agent Community
Owl for
publishing
communicative
acts
travel.owl – travel concepts
fipaowl.owl – FIPA content lang.
auction.owl – auction services
tagaql.owl – query language
Semantic Web (RDF, OWL)
Web (SOAP,WSDL,DAML-S)
Internet (Java Web Start )
Owl for
representation
and reasoning
Owl for
negotiation
Report Direct Buy Transactions
Report Contract
Report Auction Transactions
Market Oversight
Agent
Bulletin Board
Agent
Customer
Agent
Report Travel Package
Auction Service
Agent
Proposal
Direct Buy
Web Service
Owl as a
Agents
content
FIPA platform
infrastructure services, including directory facilitators enhanced to use OWL-S for service discovery
language
Owl for
Owl for
authorization
service
policies
descriptions
Travel Agents
UMBC
an Honors University in Maryland
http://taga.umbc.edu/
15
What we learned
OWL is a good KR language for a reasonably
sophisticated MAS
OWL made it easy to mix content from different
ontologies unambiguously
Supporting partial understanding & extensibility
The use of OWL supported web integration
Integrates well with FIPA standards
Using information published on web pages and
integrating with web services via WSDL and SOAP
OWL has limitations: no rules, no default
reasoning, graph semantics, …
Some of which are being addressed
UMBC
an Honors University in Maryland
16
A Love Triangle?
Semantic
Web
Software
Agents
Pervasive
Computing
Even matches made in Heaven don’t always work out as
planned.
UMBC
an Honors University in Maryland
17
UMBC
an Honors University in Maryland
18
Representing and Reasoning about Context
CoBrA: a broker centric agent architecture
for supporting pervasive context-aware
systems
Using
SW ontologies for context modeling
and reasoning about devices, space, time,
people, preferences, meetings, etc.
Using logical inference to interpret context
and to detect and resolve inconsistent
knowledge
Allowing users to define policies controlling
how information about them is used and
shared
UMBC
an Honors University in Maryland
19
A Bird’s Eye View of CoBrA
UMBC
an Honors University in Maryland
20
Security in P2P Systems
Peer-to-peer
systems are manifest at multiple
levels, such as ad hoc networking, file-sharing
applications, and multiagent systems,
Recognizing “bad actors” in P2P systems is hard
Bad actors might be having trouble, incompetent,
uncooperative, or malicious
Ad
Hoc networks can be subverted by the
introduction of malicious nodes
E.g.: blackhole routers that do not forward packets
MANETS
UMBC
an Honors University in Maryland
offer additional challenges
21
Neighborhood Watch
in ad hoc networks
Node A sends packet
destined for E, through
B & D.
When B D, B and C
make snoop entry
(A,E,Ck,B,D,E).
B and C check if D
forwarded the packet or
dropped, altered, or
misrouted it.
UMBC
an Honors University in Maryland
A
E
B
D
C
22
T.T.T: things take time
Prior
to the 1890’s, papers
were held together with
straight pens.
The development of “spring
steel” allowed the invention
of the paper clip in 1899.
It took about 25 years (!) for
the evolution of the modern
“gem paperclip”, considered
to be optimal for general
use.
UMBC
an Honors University in Maryland
23
For more information
http://ebiquity.umbc.edu/
Annotated
in OWL
UMBC
an Honors University in Maryland
24