[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Blended Authentication (AKA "Granular Access Control")


what is granular control

----- Original Message ----- 
From: "W. E. Perry" <wperry@f...>
To: "XML DEV" <xml-dev@l...>
Sent: Thursday, May 08, 2003 9:48 PM
Subject: Re:  Blended Authentication (AKA "Granular Access
Control")


> Jeff Greif wrote:
>
> > The "cartelization" being described makes Joe authenticate himself with
System
> > A, in order to use the trust relationship between System A and System B
to
> > examine your medical records (after System B verifies that System A has
a
> > right to look at your records because it represents the designated
insurance
> > provider).  Is there something nefarious about this?  Would you prefer
it if
> > Joe could access your records without this level of security?
>
> Hi Jeff.
>
> Questions of whether this is nefarious I shall leave to others. The
question of
> whether this is cartelization, however, you seem to have answered yourself
with
> this very example. As you illustrate, Systems A and B have apportioned
between
> themselves, and between themselves exclusively, the entire functionality,
as
> they understand it, of authenticating and authorizing users (and the very
term
> 'trust relationship' which you use has equally, and ambiguously, both the
> meanings 'mutual reliance' and 'collusion in cartel' [as criminalized by
the
> antitrust laws]). Your example demonstrates a priori agreement on  a) the
full
> scope of the functionality involved;  b) the comprehensive list of
participants
> who will execute any of that functionality;  and  c) the precise division
of
> that functionality between the identified participants. Those three
criteria
> define cartelization.

This doesn't seem to describe what I had in mind.  Joe is known to System A,
not to System B, which is good, because employee turnover at some health
insurance providers is high, and it's expensive for System B to keep lists
of all the claims agents for all of them.  System A *is* known (by its
authentication and authorization tokens) to System B, and is allowed to see
records for its insured parties.  System A passes on Joe's name for System
B's auditing requirements.  System A will broker Joe's transaction because
Joe is not known to System B, but System B will accept certain requests from
individuals approved by System A.  The extent to which System A is known to
System B may be only that some elements of its authentication and
authorization tokens (suitably decrypted) match elements of System B's
records of your surgery.

Thus, the parties have agreed only on the criteria for acceptability of
particpants, not the comprehensive list.  They have not agreed on the scope
of functionality -- System B has imposed requirements, and will give
information to System A if the request meets those requirements.  System A
may make requests which are denied (because a data entry error put down the
wrong insurance carrier for some patient in System B's records).  System A
might also try to update the records on System B, but this attempt would be
denied by System B (and B may impose some access penalty thereafter on A).
System B does not know what System A will do with the data that it provides,
nor perhaps, does System A know what all the data it gets means to System B.
System A may not ask for all the data that System B is prepared to give it
simply because its purposes are limited in Joe's particular inquiry about
your surgery.

There may be no agreement whatever between System A and System B.  System B
may simply announce that certain data are available under certain conditions
of authorization and authentication, to any party who can meet them.  The
particular scenario of  Joe examining your hospital records, as a legal
representative of your health service provider, just meets the publicly
stated preconditions for access to System B.

Cartelization seems a misnomer for this kind of arrangement, particularly as
you characterize it.

Jeff




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.