Subject: Re: [plasma] Delegation scenario

From: "Fitch, Scott C" <[email-masked]>
Date: Sun, 04 Dec 2011 02:20:58 +0000

Trevor, et al-
                Sorry it took me so long to reply on this. Anyway, I can see two scenarios, and two ways that a Plasma implementation could met the requirements.

The first delegation scenario is a persistent delegation such as between a Boss and an Administrative assistant. In this case, the Admin gets to read (most of) the Boss's email.

The second scenario is temporary delegation, such as assigning a role to an individual while on vacation. In this case, the delegate only has access to the messages while the delegator is on vacation.

As for ways the Plasma addresses this, it can either be done through the access rules (e.g., Boss's assigned Administrative Assistant is allowed to read company proprietary information, but not personal information) or through the assertions provided to the PDP at access request (e.g., Delegate has Role X, which meets the criteria for reading the message).

In both cases, these approaches are greatly preferable to PKI-based S/MIME, which usually involves sharing private keys, removing all granularity for access.

Let me know if that's enough to go on.

                -Scott

Scott Fitch
Cyber Architect
[email-masked]

From: Trevor Freeman [mailto:[email-masked]]
Sent: Friday, October 28, 2011 1:48 PM
To: Fitch, Scott C; [email-masked]
Subject: EXTERNAL: RE: Delegation scenario

That is a good observation. If you give a brief outline on how you see a scenario changing for delegation and I will incorporate that into the next version.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Fitch, Scott C
Sent: Tuesday, October 25, 2011 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [plasma] Delegation scenario

Plasma also opens up the opportunity to support delegation in a much more sustainable and elegant manner than current PKI-based S/MIME. I'd like to see that called out as a scenario in Section 3. Others have similar thoughts?

                -Scott

---

From: "Skedd, Richard (UK)" <[email-masked]>
Date: Tue, 6 Dec 2011 13:56:02 -0000

Plasma certainly provides an opportunity to take an approach that would
be preferable to that which we end up doing today.  A few thoughts to
add to Scott's:

Although we typically describe this as a delegation scenario, I would
describe it as one case of a shared mailbox scenario.  There are a
number of these but I don't think that the relationships between the
members of the team using the shared mailbox are important for plasma.
This could equally apply to members of a design team, a family or a
medical practice.  Messages will arrive in the mailbox.  Access to an
individual message is dependent upon the sensitivity of the message and
the privileges of the user accessing the mailbox.  Privileges are
assigned for a period which may itself be dependent on certain
conditions.

There are many examples:

-       Executive - has an assistant that is authorised for company
proprietary whilst she holds her position but not personal 

-       Manager - has a colleague that is authorised for project x
information whilst the worker is on vacation but not project y

-       Engineer - is one of five on the team that are authorised for
proprietary information from company a whilst they hold their positions
but not company b

-       Father - has two daughters that are authorised for notices about
school events whilst they are students at the school but not an
appointment with a doctor

-       Doctor - has a number of nurses that are authorised for messages
about the doctor's patients whilst they are on duty and assigned to work
with the doctor but not practice management information 

The impact of this capability on how we choose to establish and manage
e-mail addresses is another thread of discussion ...

Regards

Richard Skedd

Strategy Manager - Office of the CIO

T:    +44 117 918 8034 (vnet 7658 8034)

M:    +44 780 171 8260 (vnet 777118260)

BAE Systems plc

Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK

Registered in England & Wales No: 1470151

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fitch, Scott C
Sent: 04 December 2011 02:21
To: Trevor Freeman; [email-masked]
Subject: Re: [plasma] Delegation scenario

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Trevor, et al-

                Sorry it took me so long to reply on this. Anyway, I can
see two scenarios, and two ways that a Plasma implementation could met
the requirements.

The first delegation scenario is a persistent delegation such as between
a Boss and an Administrative assistant. In this case, the Admin gets to
read (most of) the Boss's email.

The second scenario is temporary delegation, such as assigning a role to
an individual while on vacation. In this case, the delegate only has
access to the messages while the delegator is on vacation.

As for ways the Plasma addresses this, it can either be done through the
access rules (e.g., Boss's assigned Administrative Assistant is allowed
to read company proprietary information, but not personal information)
or through the assertions provided to the PDP at access request (e.g.,
Delegate has Role X, which meets the criteria for reading the message).

In both cases, these approaches are greatly preferable to PKI-based
S/MIME, which usually involves sharing private keys, removing all
granularity for access.

                -Scott

Scott Fitch

Cyber Architect

[email-masked]

That is a good observation. If you give a brief outline on how you see a
scenario changing for delegation and I will incorporate that into the
next version. 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fitch, Scott C
Sent: Tuesday, October 25, 2011 10:57 AM
To: [email-masked]
Subject: [plasma] Delegation scenario

Plasma also opens up the opportunity to support delegation in a much
more sustainable and elegant manner than current PKI-based S/MIME. I'd
like to see that called out as a scenario in Section 3. Others have
similar thoughts?

                -Scott

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************