OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Blended Authentication (AKA "Granular Access Control")

[ Lists Home | Date Index | Thread Index ]

Jeff Greif wrote:

> 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.

I think that you are describing one sort of system architecture and I am
describing another. The salient differences are that in your architecture

    -- Systems A and B know of each other's existence and have at least general
understanding of the nature of each other's functionality--enough for each of
them to understand the border or the difference between their respective
functions

    -- Systems A and B both present public interfaces which, if specific,
disclosed input requirements are satisfied, will prompt the system to execute
its particular function. What may not be so publicly understood is the outcome
of that function--that is, the data product which the system publishes or
otherwise makes available. The interaction of each of these systems with their
public users is designed around what they consume (the input interface) rather
than what they produce

whereas in the design I propose

    --systems do not need to know who consumes what they produce, nor for what
purpose or with what semantics, and certainly do not know such things a priori
as the basis of their relationships with those consuming systems. In my
architecture the relationship between autonomous systems (or indeed any
functional nodes) is always 'webbed', never linear, always uni-directional,
never bi-directional, because a bi-directional exchange would require that a
system knew what was downstream of it, and with what semantics attached to its
processing of the data shared between those systems

    --systems publish their output in a form retrievable by, paradigmatically,
an http GET. Systems do not publicize nor predictably respond to input
interfaces. A significant part of a system's necessary expertise is knowing
where among published data outputs to find the data which it requires as input
and how to instantiate what it finds into the form which it requires for its own
processing.

> 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.

That is in large part an overview of a system built according to my principles.
I think that when you flesh out what you describe here with implementation
details you will find that you have something *very* different from what Joe and
John and probably even you envision. Many people do react in horror when they
see systems built to these principles or realized their implications for
(lacking a more precise term) the expected cartelization of function among
systems know a priori to one another.

Respectfully,

Walter Perry





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS