[plasma] Plasma Use Cases - B2B

["James Schaad" <[e-mail]>]

Going back to the set of use cases in the draft.  I am going to propose a
greater set of cases that need to be looked at.  Since I am still of the
opinion that ABFAB provides a good architecture to build on, the terminology
that I am going to use is what I consider to be the best ABFAB terms (they
sometimes get themselves mixed up by multiple naming).

Cases:

1.  Everybody is located in one location

Sender, Receiver (both subjects), RP and IdP are logically in the same
location.

In this case normal ABFAB processing works as everybody can easily
understand what is being asked for and there is a single set of attributes
that would be defined for usage.  In addition to using the IdP w/EAP to get
identity information, it would be avoid talking to the IdP in some
situations either because of a prior communication w/ the RP.  Additionally
one could see the identification operation being done by the use of a
locally assigned ticket when accessing the current domain (i.e. a Kerberos
ticket or authenticated RPC).  It would also be possible to use PKI rather
than EAP as the authentication feature w/ the use of attribute certificates.

2.  Sender and Receiver at different locations

Location A - Sender, RP, IdP_A
Location B - Receiver, IdP_B

The IdPs are run by the same organization, and thus will have the same basic
information.  The IdPs might in fact be replications of each other (on the
assumption that a person from location B should be able to login at location
A).  Issues that need to be address in this case are:
a) What happens if the attributes that can be attested by the different IdPs
are different?
b) What happens if the IdPs are currently out of sync?
c)  What logic is needed to identify the other IdP if needed.  Does this
need to be supported by AAA or not?

3.  Sender and Receiver at different locations - different IdP systems

Location A - Sender, RP, IdP_A
Location B - Receiver, IdP_B

The IdPs are run by different organizations, but they have some type of
basic federation infrastructure which establishes both a trust relationship
as well as a policy mapping system for policy decisions.   This is the
classic ABFAB case.

4. Sender and Receiver at different locations - multiple RPs

Location A - Sender, RP_a, IdP_A
Location B - Receiver, RP_b, IdP_B

In this case it is assumed that each RP is a replicate of the other
(although with  different keys) and that the same policy code is installed
on both system.  If the IdPs are not replicates, then it is assumed that the
policy module at each location understand the necessary mapping of
attributes.  The RP_a would include lock boxes for both RP_a and RP_b in the
message so that works seamlessly.  

In some cases the sender and receiver could be in different companies.  In
this case there would be questions if RP_b was under the control of company
A or company B.  In the first case we keep the same set of legal and fiscal
liabilities - i.e. the PDP is still under the control of company A.   In the
second case the information release would under the control of company B
which might cause problems, but would be more acceptable from a system
maintenance point.  (Keeping the RP_b in a DMZ might deal with some of these
issues.)

5.  Sender and Receiver at different locations - receiver does not have its
own IdP.

Location A - Sender, RP, IdP_A, IdP_external
Location B - Receiver

In this case there is an agreement between the two entities, but it is not a
federation arrangement.  Instead an IdP is provided by the sender's
organization to a set of individuals external to the location by which those
individuals can identify themselves to the RP. 

Are there other B2B cases that people can think of?

Jim